大型网站运维：从系统管理到SRE

作者简介

顾贤杰网易运维专家、SRE团队Leader，10多年来一直聚焦互联网业务运维和稳定性建设。在互联网业务运维方面经验丰富，曾负责网易博客、相册、即时通信、支付、电商、账号系统、云音乐等众多产品的运维工作。在金融支付机房设计、高性能负载均衡建设、业务双机房改造部署、灾备建设等多个运维领域均有实践，设计过海量服务器运维工具平台，负责的产品服务了上亿的互联网用户。目前的运维研究方向：海量服务器稳定性治理、基础设施即代码、混合云/云原生体系下的运维平台建设。徐 S网易资深运维开发工程师，运维开发团队技术Leader。参与并主导杭研运维体系建设，包括监控、流程、发布、审批等运维领域。持续探索运维自动化、智能化、一体化建设，为网易云音乐、网易传媒、网易支付等上百个产品提供高效稳定的运维服务。颜中冠网易技术经理、资深架构师，有16年的互联网一线研发和架构经验。曾负责亿级统一认证项目，主持网易帐号异地双机房建设，以及网易云计算业务中台搭建，负责多个对外亿级商业化项目研发。

内容简介

2.2 SRE工作着力点 SRE团队每天都会执行大量的运维操作，线上的运维需求源源不断，如果不对线上的运维需求进行良好的梳理和归纳，没有形成针对业务的运维能力输出，业务团队很容易将SRE团队和传统运维团队等同看待。在大型公司内部，虽然业务团队会使用公司共有的基础设施和流程，但是在某些方面还会形成业务团队独有的运作方式和风格。业务团队独有的运作方式和风格，可能对SRE团队推行统一的工具或流程有一定的阻碍。不同的业务风格会非常挑战SRE团队的工作能力，可以说这是最考验SRE团队工作的部分。 从公司层看，SRE团队可能会同时对接多个业务线，SRE团队日常的工作会在多个业务线间来回切换。SRE团队的日常工作一方面是运维任务跟进；另一方面是针对不同的业务团队，设计、适配、推广不同的运维工具或架构。 制定运维计划后，就得开始考虑将制定的运维计划落地。针对各个业务团队情况，SRE团队在做技术工作前还需要做一些关于人或团队的工作。 1．融入团队 如之前所说，在新的业务模式下SRE团队会直接和业务团队一起工作，但一起工作并不代表SRE团队会了解业务团队。为了能够顺利开展工作，SRE团队需要对业务团队有深入的了解，了解业务团队的成员架构、开发模式、沟通“语言”。只有深入地了解业务团队后，SRE团队才能很好地和业务团队中的其他成员用一样的“语言”交流。要求SRE团队成员有开发工程师背景很重要的一个原因就是：只有程序员才知道程序员的术语。当一个程序员说堆栈溢出、自旋锁、CPU Cache Line等术语时，传统运维工程师可能无法理解术语真实的逻辑，而SRE工程师和程序员用一样的术语沟通，可以正确理解对方描述的业务特性和场景。例如，要了解“00后”就得用“00后”的“黑话”。用同样的“语言”沟通，一般会有更多的认同感，业务团队和SRE团队之间的沟通会没有隔阂。另外了解业务团队的架构，可以让业务团队和SRE团队之间的沟通和问题处理变得更加高效，不至于出现有问题时却不知道找谁的情况。 2．建立信任获得授权 用传统的运维方式跟进业务时，有时候难免在运维操作或理解上出现误差，导致业务团队质疑运维团队对线上问题的判断方式和处理逻辑。运维团队的某个成员搞出一个线上事故后，会发现业务团队看待他都是戴着有色眼镜的。传统运维团队转变为SRE团队后，为了更好地运维线上产品，SRE团队会尤其注重和业务团队的关系维护。 团队间要建立信任，可以说非常简单，也可以说非常困难，但是最根本的还是看技术，粗暴点说就是，“shut up,show me code”。传统运维团队想在技术上让业务团队信服，除非很巧合地遇到了线上业务故障，运维团队用自己的专业技能力挽狂澜。但不幸的是，更多的时候是运维团队被业务团队发现操作不规范和考虑线上问题不全面等问题。简单来说就是运维工程师感觉自己空有一身“本领”，但是没有合适的地方输出，某次操作失误会导致形象崩塌。所以传统运维工程师总是处于公司内部人员的“鄙视链底端”，就连运维工程师自己也常调侃自己是“背锅”的。 在传统运维团队转变为SRE团队的过程中，传统运维团队也对这方面问题有过担忧。但在实际落地时，传统运维团队惊喜地发现转变之后的SRE团队在获得团队信任方面有自己独特的优势。相比传统的运维团队，SRE团队深入业务底层，同时具备程序员的“黑话”能力，对线上问题的沟通和判读会更加容易被开发团队理解和认可。 例如，之前有一次，SRE团队的运维工程师直接坐在开发工程师后面和他一起Review线上代码逻辑，运维工程师通过对代码逻辑的解读和讨论，迅速地和开发工程师达成了线上运维操作的逻辑和设计。相比传统运维团队只凭直觉和经验去挑战开发工程师的实现思路，这种工作方式的转变是一个巨大的飞跃。传统运维工程师只通过自己的经验或直觉和开发工程师沟通，很多时候是和开发工程师之间存在一定隔阂的，转变思路后和开发工程师一起用开发工程师的方式处理问题才是更可行的办法。 SRE团队得到业务团队的信任，往往是为下一步工作做铺垫的。当业务团队开始信任SRE团队的稳定性保障能力后，SRE团队就可以推动一些运维技术或架构的改变。SRE团队执行一些稳定性改进策略时，会要求开发团队配合性地做一些业务逻辑外的事情，因为开发工程师会对业务逻辑外的事情有一些抵触情绪，如果处理不好，开发工程师会直接改进事项，所以SRE团队获得业务团队在某方面的授权就变得尤为重要。 SRE团队很有必要在技术之外加强自己的沟通、说服能力。传统的运维团队要得到某个事项的授权，一般的流程是说个方案，然后找领导沟通，通过上层领导授权去推动这个事项的落地。SRE团队则会选择向业务团队解释他的方案，和内部沟通一致后得到授权。相比之前的方式，SRE团队得到授权的方式显然更加容易得到业务团队的支持，更容易推行SRE团队想推行的东西。 3．推动业务发展 可能有人会说运维团队和业务发展有什么关系，只要保障业务稳定就好了。这个想法其实是有问题的。公司为什么要有运维团队？抛开技术不讲，从老板的角度看，运维团队就是为了线上不停摆，为了业务顺利发展，为了业务不受损失，整个公司的资源都是为了业务发展而准备的，所以反过来讲如果运维团队能推动业务发展，那么是不是就能获得更多的资源呢？ 传统运维团队其实能做的事情和业务不是很多，更多的是被动地应对业务的需求变化，可以说是被业务拖着走的，这是因为有以下两个因素。 （1）传统运维团队和业务团队有隔阂，没有很多的沟通，平时无从谈起对业务的了解。 （2）传统运维团队处于被动接受需求的一方，了解并深入业务层的特性不是传统运维的绩效指标。 当然这些情况也在发生一些变化，如最近两年越来越多的运维工程师会有危机感，进而提到要转型做业务运维工程师。这其实也说明了一个趋势：传统运维都意识到了新技术的挑战，不得不转型。 从我个人转变的感触来说，转变为SRE后，运维团队针对业务层面的需求可以做更多的事情。例如，之前有遇到一个业务上“服务发现”的需求，粗看是开发代码的问题，传统运维团队可能就会想这个需求是开发团队的工作，运维团队不用参与。但如果细致地分析业务需求和设计逻辑后，就会发现这个需求完全可以通过SRE的工具链结合少量的代码开发来完成。SRE团队在业务层越深入，开发的工具可能就越完善和丰富，这样的场景也会越来越多。 另外相比之前系统管理员、应用运维工程师等运维角色，SRE团队会更加注重以产品的角度看运维，而不只是简单地完成业务的运维操作需求。SRE团队通过梳理业务特性、制定业务流程、定制自动化工具等多种方式，主动地改进业务的迭代效率，简单来说就是提升产品发布等各个环节的能效，同时通过积极的策略（使用自动化工具和SRE手段）来降低迭代速度带来的不稳定因素。 网易运维专家、SRE团队Leader顾贤杰领衔撰写，凝聚了网易10年百亿级别大型系统运维经验，值得阅读！从Google SRE到网易SRE的实践之旅，中国技术团队的实践总结！