您好邵总，请您先做个自我介绍吧，聊聊您的履历和现状，让大家更好的认识您，了解您的背景也有助于读者理解后面的采访内容
我是来自又拍云的邵海杨，从 1998 年开始使用 Linux 至今快 25 年了，资深 (老鸟)Linux 系统运维/架构师，DevOps 八荣八耻倡导者，业余撰稿人；精通 (心虚) 系统优化及网络服务管理，Linux 系统定制，CDN 加速和安全防御; 擅长互联网高性能网络及架构设计、虚拟化 KVM 及 OpenStack 云平台，K8S 容器云和 Ceph 分布式存储等新技术；喜欢交流分享，活跃于社区，一直积极投身于开源活动的组织和传播。
运维领域，每个公司都会制定自己的运维准则或者操作规范，能否分享一下贵司的经验，给我们一些参考？
又拍云是一家提供云存储，云分发，云处理服务的公司，也是国内首创可编程 CDN 服务的专业云服务提供商，特点就是 7x24 全年不间断服务，所以云运维也有一些律条或原则，比如：
先保障稳定，然后再优化
过度设计或过早优化很可能会带来更多的故障停机时间，要先集中精力提高系统的可扩展性和高可用性。坚持“先完成，再完善，后完美”，项目也是“先能用，再好用，后用好”的实施策略。
提供可靠的测试依据和时间验证
引入新技术到架构之前，要确保新技术的稳定性和足够时间久的考验，更要有运维工程化中开发出来的工具链的完整。一旦线上返工或变更造成的措手不及可能已经是故障的导火索。
使用可控的自动化手段提升效率
自动部署、自动编排、自动巡检、自动升级等自动化手段越来越多应用于云运维。这是适应云计算时代的趋势，但能力越强，责任越大，要谨慎自动化的雪崩和惊群效应，做好灰度/蓝绿部署和各种测试。
保持简单，监控一切
保持简单，别把事搞得太复杂。除了常见的异常问题报警外，面向业务指标，市场指标和销售数据，成本等都可以用来做趋势分析信息。定期的轮询查看各个趋势数据的峰值峰谷有助于见微知著。
面向预算的运维
运维团队通常是最大的花费者，因为预算不足，没有钱的运维是很难兼顾到日益增长的公司业务规模，除非公司业务已经停滞或不再有爆炸式的增长，面对这样的挑战，运维要学会降本增益，开源节流，利用新技术实现能效比的提升。
面向场景的智能运维
各种各样的负载场景，从高并发处理到视频转码，从高性能并行计算到海量的网络请求。这些不同的负载场景，对网络带宽，各种处理和 IO 的要求也各不相同。智能运维就是需要深入理解业务，合理配置资源和架构来满足不同业务场景的需求。
持续集成和发布系统
持续发布包括灰度发布、测试发布、滚动发布、回滚发布等多种场景，并且确保每种场景都应该是可以可控的。
确保任何人都可以被替换
铁打的营盘流水的兵，人挪活是常态，做好员工的共享文档管理和知识传递和分享，理论上所有人都可以被替换，任何人也不应该成为公司的天花板。
虽说成长是自己的事情，但如果有合适的场域、合适的项目机会、合适的团队、合适的机制，会让工程师的成长更快，团队更有战斗力，您能否系统的谈一下是如何促成运维同学的成长的？
公司一直是积极鼓励员工的技能自我提高和促进成长：
每月开放日：公司内技术委员会会定期举办讲座，分享前沿研究中的一些收获，要求有主题，有重点，有应用场景，最好有实例。
每周分享会：鼓励所有开发者定期分享新的技术，谈论他们面对的问题，或者任何别的他们正思考的东西，分享的内容会形成文档和视频存档，并根据评分给予奖金和积分激励。
公司悬赏项目：无论是公司还是员工自身都可以发起项目，技术委员会评审通过后，自行组队完成，根据产出文档，数据对比，技术分享后获取相应的项目奖金。申请专利还有相应的专利奖金。
培养个人影响力：鼓励员工通过发表文章或演讲的形式，走出去做工程经验分享、工作心得的梳理，提高个人的影响力，并根据受众的反馈给予稿费和讲师费激励。
订阅报刊，杂志等纸质书籍，了解最新动态。以部门为单位，配置一定的购书津贴。
又拍云运维团队内的培养包括：
化“天花板为托板”：把自己放在一个培养新人的管理角色，不让自己成公司瓶颈和员工的天花板，鼓励新人们去尝新和处理故障，增加自身的技能和实战经验；信任，互助，激励，他们会持续不断创造惊喜。
制作“自动化工具”：利用自己的经验抽象业务成程序模型，制作或培训自动化脚本的编写，提高团队的工作效率，让员工节省精力和时间去学习其它新知识；
承担“高精专”项目：提前准备最新知识的研究和可行性分析，整理成文档作公开培训，再交给团队去深入研究和实施，转化成生产力，积累一线经验再反馈完善文档，良性循环；
积极提倡“知识分享”：各种案例和“坑”都会整理成 wiki 文档，通过文档共享，定期分享讲座，鼓励员工撰写高质量的，可读性很强的文档，开口培训，增加感染力和自信心；
鼓励“参与开源交流”：公司鼓励员工走出去参与技术交流大会，闭门造车耗时耗力，不如专业的人点拨。也会有购书经费，团建活动经费，茶歇文化；
运维工程师其中一个典型的职业路径是做管理者，但管理者和资深运维要解决的问题截然不同，对于那些刚刚步入管理岗的资深运维，是否可以分享一些您的经验？
对于刚步入管理岗的运维来说，我的建议是及时梳理遗留的技术债和人才技能的盘点和培养，先打好基础，后面才能有更大的空间进步，具体可以参考我的《DevOps 的八荣八耻》的分享。
一、以可配置为荣，以硬编码为耻
二、以互备为荣，以单点为耻
三、以随时重启为荣，以不能迁移为耻
四、以整体交付为荣，以部分交付为耻
五、以无状态为荣，以有状态为耻
六、以标准化为荣，以特殊化为耻
七、以自动化工具为荣，以手动和人肉为耻
八、以无人值守为荣，以人工介入为耻人
才上技能树的盘点，主要是配合人事做好人才九宫格的划分（如果是开发或运维，把左侧的绩效换成潜力，绩效针对销售而言），考查的是管理者对员工的全方面的辨析能力，知人善用。
再结合公司的 OKR 目标管理来激励员工，它的优点在于聚集目标的同时，还能：
激励个人自驱力，鼓励员工创新和反思；
考查的是相对结果，鼓励有难度的挑战和突破；
考核的协同配合能力，鼓励员工去全方位的协调推进；
Kubernetes 火了好一段时间了，很多公司也在大规模应用了，但显然，每个技术都不是银弹，无法解决所有场景的问题，这几年观察下来，您觉得哪些公司不适合上 Kubernetes？能否给一个这类公司的画像，并说明理由？
虽然 Kubernetes 代表着目前为止的 devops 的最佳工程应用实践 (真香)，但也不是所有场合都能应用，如又拍云的 CDN 边缘服务器，数据中心的日志分析平台，Ceph 分布式存储就以物理机为主。所以，我建议找一些合适的场景先试用起来，如：
机器资源错峰空闲浪费严重的；
CPU，磁盘和网络 IO 都不密集的；
不需要持久化存储的或抢占资源的；
软件架构已经做了微服务改造的；
业务处理程序有周期性、可弹性扩容的；
运维和研发是最亲密的伙伴，贵司是如何做工作边界划分的？另外关于如何让这两个角色保持亲密合作，是否可以分享一些经验？
运维工程师 = 冲锋陷阵的将军
软件工程师 = 坐阵帐中的军师
理论上，优秀的软件工程师是可以把部分 (甚至全部) 运维工程师的工作做掉，比如说业务软件性能的监控，如果程序员在程序中插入很多的钩子或探针，就可以统计出数据来，不需要运维劳心劳力的监控；比如说程序员在设计程序的时候，考虑到了分库分表，考虑到了大并发和分布式的设计，那运维就可以水平扩展机器就行；如果软件没有那么多 bug，还有很多如果......但是，现实是残酷的，这种高水平的程序员太少了，尤其在中国，大家都忙于实现业务功能，连个文档甚至注释都不愿意写，更别提能够考虑这么周全了；同理，运维接触的很多是开源很优秀很成熟的软件，从中是可以借鉴知晓优秀软件是怎么设计的，比如优秀的程序，日志信息会非常详尽，我们可以通过标准的 syslog 或者日志去监控它，所以，资深的运维会：
积极参与事前的规划，配合开发做演练，自动化部署，协助架构改进
合理提需求，要资源，最好是有预算，做到防患于未燃
线上监控，故障复盘，反馈给整个团队，倒逼上下协调做改进
当然，要达到上述能力的运维管理，肯定需要潜心研究，承上启下，协调团队，任劳任怨的修行多年，到那个时候，运维就不再是对事情的结果负责，而是转变角色，主导和协调整个过程。当然，这里指的能力不仅仅是技能，还包括对业务的理解能力，站在公司管理层面对整个项目和资源的分配和把握。因此，运维工程师其实是现实中的软件工程师的互补，因为大家的能力侧重点不同，所以大家更要团结一体，要能够打胜仗，离开谁都是不行的，这是一个共同修炼进步的过程。
最后，我的个人观点：架构师它可能不是一个人的角色，而是一个团队的统称，它可以：
不必冲锋陷阵，就可以纵观全局，运筹帷幄，调度所有的资源（运维架构师的功能）
可以带领和团结团队，高屋筑瓴，因时制宜的实现解决方案（软件架构师的功能）
可以把握公司业务方向和深度，洽谈合作，控制成本（业务架构师的功能）
运维需要和其他多个部门沟通协作，鉴于各个团队目标关注点未必一致，合作起来可能未必有那么顺畅，针对这个问题您是用什么招来让这个过程更加顺畅的？
其实沟通不顺畅的原因大部分在于对后果的不可预见性，你说冗余他说预算，你说架构他说工期，各有立场又各有苦衷，但就是没人对结果负责。我在工作中发现，当故障发生时，各部门的配合是空前团结，战斗力也是最强的，所以，沟通协作的关键在于： 既要团队协作，也要责任分明
事前部门沟通时，确定好项目预期，成本，影响要素，故障后果及责任方；
事后故障复盘时，根据故障原因，有理有据地“甩锅”，同时要引以为戒，亡羊补牢；
比如说提供在线 10W 并发的能力，需要冗余带宽冗余服务器数量 x2，因为预算不足减半所导致的后果及责任人；再比如软件设计不好，通过性能监控，发现指标异常的后果及责任人；当然，报警处理不及时，人为操作故障也会算到运维亦无可厚非；故障文化就是要关注问题和关注事情本身，对事不对人。大家都在故障中成长，在复盘中变强。
您觉得运维工作最重要的几个目标是什么？您是怎么落地这些目标的？
运维自动化；
监控常态化；
日志可视化！
这个篇幅太多了，不展开讲，可以参考《云运维的启示和架构设计》
工具选型这块，到底是自研，还是使用开源，还是使用商业产品，是如何抉择的？
又拍云通常不会重复造轮子，但一定会先用好轮子，或者把轮子改造得更加称手，选择自研往往具备了一定的开发能力，再加上某些必要原因，如：
找不到符合要求的开源软件，如我们自研的云处理软件…
开源软件有 bug 或者 issue，社区短期内无法推进，但业务又急需，只能通过自研解决，如 ats 的内存泄露问题…
开源软件的功能特点跟公司的业务不相符合，不得不改造软件，如 nginx 的防盗链模块，需要与客户对接定制…
开源软件的设计目标过于高大上，通用性好但很臃肿，如果我们只要某个小功能点，就不需要牛刀了，如性能探针的埋点…
有数据保护要求，或者有隐私的场合…
越来越多的公司在迁往公有云，云原生架构下，SRE 团队的核心职能是否有些变化？应该如何凸显团队的价值呢？
公有云作为 IaaS 基座，容器云作为 CaaS 中间层，云原生作为 SaaS 应用层，整个云生态日新月异，SRE 团队的核心职能会更加注重顶层系统性的容量规划，指标监控，高可用性和分布式的弹性设计，所以跨平台跨部门的职能互补、团队协作、持续精进、勇于承担包括：
积极参与事前的规划，配合开发做演练，协助架构改进；
合理提可用性需求，冗余资源，最好是有预算，做到防患于未燃；
线上监控，故障分析，反馈给整个团队，倒逼上下协调做改进；
团队的价值就在于是否总是能够接受新事物，新的挑战，各施所长，不做井底之蛙，也不是温水煮青蛙，在创新或者颠覆来临的时候，也能保持不被时代脱钩。
对于运维工程师个体，SRE 的转型路径是？应该注意些什么？
技术领域
学会抽象业务模型，标准化组件，定制化脚本，自动化部署，提升整体效率；
学会收集日志和日志分析并可视化，提升运维监控和预警报警的效率；
掌握和熟悉一门或若干语言，能够帮助你成长，提升你的战斗力；
勤做笔记，温故而知新，学思结合，要学会沉淀，举一反三；
勇于面对新兴技术的挑战，打不过就学它；
非技术领域
学习能力，要知识面广；
沟通方面，了解客户的精确需求；
技术风险、人工、进度等成本，权衡取舍；
社区活动，积极分享，锻炼口才和交流能力；
提升自己的影响力，学会与人同行，可以交到更多的朋友；
面对当下快速发展的基础技术，您对给刚入行和入行已久的运维人员，分别有什么职业规划的建议吗？
首先不是工作选择人，而是人选择工作，一个人若对某方面有了兴趣，真正用心学习了近 10000 个小时，其实做什么都是可以的。比如说我毕业那个时候，都是强调复合型人才，根本没有运维这个职业，我们不光自己攒 (DIY) 机器，自学 Linux 操作系统，还学习编程，折腾网络，自己动手写论坛聊天室等程序；Linux 给我们带来的是每天都有创新的，好玩的，优秀的开源软件让我们保持激情去尽情的折腾和学习，当互联网兴起的机会来临时，做个运维总监其实也是顺理成章的事；其实，除此之外，我还转型做过售前，技术支持，跑过市场，经常做演讲培训，所以真正的高手是什么不会学什么，技多不压身，做个懂业务、会开发的运维工程师。
您觉得运维人员最重要的素养是什么？对新入行的运维人员有哪些寄语？
我认为最重要的能力是表达沟通能力，但不排除运维本身所需的技术储备、实践动手能力、编程能力和学习能力。考虑到运维大部分还是一个成本支出的岗位，如何把深奥隐晦的性能及瓶颈指标，用直观的图表展示来获取上层持续的投入是需要技巧的；然后面对你的同事，你的兄弟部门，也需要你的影响力去协调推进工作，如果能够做到这些，说明你已经具备了领导的才能，这样以后做什么事都会站在更高的水平，用全局观的格局去统筹规划整个项目的目标，人员，工期和资源的合理分配和把握。