运维部要保证产品业务的稳定性，开发部要随时随地快速上线新功能，上线失败往往是因为新的变化——无论是发布新版本、修改配置，还是改变某些用户行为导致流量负载发生变化，传统上两个部门在本质上都有相对的目标。因此，运维部门往往要求开发部门对变更或发布进行管控，规定必须遵循一些繁琐的流程；而开发部门会尽量绕过这些繁琐的步骤，支持新功能更快上线。Google的工作方式：面对运维部门和开发部门之间产品稳定性和迭代创新速度的矛盾，在设定的“错误预算”内允许产品出现异常，通过可量化的SLO来实现两个目标.他们之间的平衡。例如，一个产品的可用性目标是99.99%，只要该产品当前可用性高于99.99%，运维团队就会尝试加快产品功能的上线速度；当由于变更等意外导致产品可用性低于99.99%时，新的上线和变更请求将在下一个可用性审查周期之前处理。结合我们的工作思考：运维部自成立之初就建立了产品可用率体系，与产品一起设定可用率目标。可以说在量化运维质量目标和平衡产品迭代速度方面做得很好。可以改进的是提升产品开发部门对可用性目标的重要性和事故改进的协作程度。一些产品往往以牺牲产品稳定性为代价，一味追求产品迭代创新的速度，在事故改进上投入的精力不足。2、运维工作的工程化GoogleSRE通过软件工程来提高运维效率和解决问题，鄙视人工操作。堆人的方式远远不够。二是GoogleSRE对自身工作的定位和追求。它采用开发软件工程模式，摆脱繁琐重复、机械的工作，深入系统架构和业务。提高自身运维效率和整个系统的可用性和可靠性。对比思考：近两三年，随着网易云音乐、考拉海购等产品业务的快速发展，航研系统整体服务器规模也快速增长，统计的支撑工单数运维部也从2016年上半年的日均人数210人上升到2016年下半年的315人，2017年上半年319人。在总体人数保持稳定的情况下，持续改善在操作和维护效率方面是需要的。为此，整个运维部门决定在2017年初实施DevOps战略，并为提升运维工作效率设定了明确的量化目标，包括工单处理时间、自动化完成率、开放性和自助性等。同时，在运维平台建设方面，将在流程串联、数据互通、效率提升等方面进行更多的优化和改进；此外，为了优化日常工作，运维部的PE、SA、DBA等组都开发了自己的管理平台——Phoenix、FL、OWL，这些系统的数据和流程将打通.到2017年底，我们的目标是50%的工单可以由开发部完成，大部分业务可以由四通移动处理，整体工作效率同比提升50%以上——年。3.Trivia和on-call轮换GoogleSRE强调将日常琐事的工作量控制在50%的上限，让一半的时间可以投入到工程开发上。琐事，包括值班值班、业务中断（工单、邮件、IM）、发布、数据更新恢复相关等。日常琐事太多，工作经常被打断，是无法提高效率的问题运维工作。GoogleSRE有两种主要的方法来解决这个问题。一是采用on-call轮值制，让部分人参与；二是对运维杂务工作量进行整体考核，增加人手或将运维工作转移给开发部门，控制运维工作的比例。整个部门的琐碎任务。对比思考：“工作经常被打断，低技术问题太多，开发轮番换，重复问题一遍遍回答……”等等，也是运维人员经常遇到的最大问题抱怨。.我们也早早安排了值班，但由于每个产品业务的独特性和复杂性，值班人员只能处理少量的日常工单，大部分工单仍需要分配给非-值班人员，所以总的来说大家日常琐事很多，尤其是咨询工作，往往一个运维人员就有20多个IM对话窗口。我们的答案：小石头机器人可以回答常见问题。我们也做了文档总结和FAQ，方便开发部门学习，但是实践下来整体效果不理想。实时互动问答，问题更集中，对用户来说是一种更快捷、更高效的方式。为此，我们将尝试将FAQ做成智能客服机器人，将小石头机器人接入夸服等常用平台页面，解答用户常见问题。我们要做的是不断更新FAQ，让智能机器人更准确地匹配答案，引导用户使用小石头。值班可以处理更多的工作。通过标准化、平台化、WEB化的日常工作，屏蔽了值班人员不同产品业务工作的独特性，依托于我们每个平台的建设，我们将在未来继续投入精力。开放自助服务，输出运维能力。通过流程控制、任务自动化处理和风险控制，利用夸富等平台，让开发等部门自行处理日常需求。目前已经尝试了NDP发布平台、OWL缓存管理等。后续夸服新工单系统将改造原有流程，Q3将实现工单自助操作，并持续开放更多类型工单的自助服务。4.人才招聘与培养谷歌的SRE人才招聘遵循与软件开发工程师相同的标准，SRE团队也有不同行业背景的优秀人才，比如原先负责美国国防部的GPS和惯性制导系统。陆空交通设施，原来是救生员，原来是设计军用飞机等地面管理系统的，原来是合成砖厂的工程师，原来是核潜艇工程师等等，都对安全性、稳定性、可靠性。邮政。在培训方面，建立系统的培训课程，吸取事故经验总结，承担挑战性项目，尽早参加on-call试用工作。对比思维：我们做的还行：重视招聘一直是我们部门的传统，让所有招聘主管的招聘标准都是一致的。除了考核专业能力，我们还制定了合作和执行的标准。需要工程思维。以前应聘者回答“为什么选择运维岗位”时，他说“我不喜欢开发工作”，虽然我们各方面能力都不错，但还是没有选择她。我们可以借鉴的：逆向工程思维的培养，我们可以做更多的破坏性工作和维修演练；让新人承担一些有挑战性的项目。另外，我们可以多关注其他行业的优秀人才。最后，开发和运维并不天然矛盾。它们只是需要被确立为产品开发的共同目标，并在产品创新速度和稳定性之间找到平衡点。我们在思考自己的运维工作时，会一直坚持以上观点。以上是我们在阅读了GoogleSRE这本书后结合自己的工作所做的一点点思考，以及对我们后续工作改进的一些方向。
