您好邵总，请您先做个自我介绍吧，聊聊您的履历和现状，让大家更好的意识您，理解您的背景也有助于读者了解前面的采访内容
我是来自又拍云的邵海杨，从 1998 年开始应用 Linux 至今快 25 年了，资深 (老鸟)Linux 零碎运维 / 架构师，DevOps 八荣八耻倡导者，业余撰稿人；精通(心虚) 系统优化及网络服务治理，Linux 零碎定制，CDN 减速和平安进攻; 善于互联网高性能网络及架构设计、虚拟化 KVM 及 OpenStack 云平台, K8S 容器云和 Ceph 分布式存储等新技术；喜爱交换分享，沉闷于社区，始终踊跃投身于开源流动的组织和流传。
运维畛域，每个公司都会制订本人的运维准则或者操作标准，是否分享一下贵司的教训，给咱们一些参考？
又拍云是一家提供云存储，云散发，云解决服务的公司，也是国内首创可编程 CDN 服务的业余云服务提供商，特点就是 7 ×24 全年不间断服务，所以云运维也有一些律条或准则，比方：
先保障稳固，而后再优化
适度设计或过早优化很可能会带来更多的故障停机工夫，要先集中精力进步零碎的可扩展性和高可用性。保持“先实现，再欠缺，后完满”，我的项目也是“先能用，再好用，后用好”的施行策略。
提供牢靠的测试根据和工夫验证
引入新技术到架构之前，要确保新技术的稳定性和足够工夫久的考验，更要有运维工程化中开发进去的工具链的残缺。一旦线上返工或变更造成的措手不及可能曾经是故障的导火索。
应用可控的自动化伎俩晋升效率
主动部署、主动编排、主动巡检、主动降级等自动化伎俩越来越多利用于云运维。这是适应云计算时代的趋势，但能力越强，责任越大，要审慎自动化的雪崩和惊群效应，做好灰度 / 蓝绿部署和各种测试。
放弃简略，监控所有
放弃简略，别把事搞得太简单。除了常见的异样问题报警外，面向业务指标，市场指标和销售数据，老本等都能够用来做趋势剖析信息。定期的轮询查看各个趋势数据的峰值峰谷有助于见微知著。
面向估算的运维
运维团队通常是最大的破费者，因为估算有余，没有钱的运维是很难兼顾到日益增长的公司业务规模，除非公司业务曾经停滞或不再有爆炸式的增长，面对这样的挑战，运维要学会降本增益，开源节流，利用新技术实现能效比的晋升。
面向场景的智能运维
各种各样的负载场景，从高并发解决到视频转码，从高性能并行计算到海量的网络申请。这些不同的负载场景，对网络带宽，各种解决和 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 给咱们带来的是每天都有翻新的，好玩的，优良的开源软件让咱们放弃激情去纵情的折腾和学习，当互联网衰亡的机会来长期，做个运维总监其实也是牵强附会的事；其实，除此之外，我还转型做过售前，技术支持，跑过市场，常常做演讲培训，所以真正的高手是什么不会学什么，技多不压身，做个懂业务、会开发的运维工程师。
您感觉运维人员最重要的素养是什么？对新入行的运维人员有哪些寄语？
我认为最重要的能力是表白沟通能力，但不排除运维自身所需的技术储备、实际入手能力、编程能力和学习能力。思考到运维大部分还是一个老本收入的岗位，如何把深奥费解的性能及瓶颈指标，用直观的图表展现来获取下层继续的投入是须要技巧的；而后面对你的共事，你的兄弟部门，也须要你的影响力去协调推动工作，如果可能做到这些，阐明你曾经具备了领导的能力，这样当前做什么事都会站在更高的程度，用全局观的格局去统筹规划整个我的项目的指标，人员，工期和资源的正当调配和把握。