SRE相关问题答疑

1.SRE是什么，怎样才能成为一个合格的SRE？

SRE全称是（Site Reliability Engineering），这个职位称为站点可靠性工程师。

要想成为一个合格的SRE，首先也是最重要的一点是一个合格的工程师，能够使用计算机科学和软件工程手段来设计和研发大型、分布式计算机软件系统，能够运维在分布式集群管理系统上运行的具体业务服务。产品团队的工程师专注于做业务相关的研发，而SRE工程师则重点关注这个系统的额外组件的研发：比如监控系统、备份系统、负载系统等，专注于对其负责的软件系统架构设计、运维流程的不断优化，让这些大型软件系统运行得更可靠，扩展性更好，能更好的利用资源。

2.您认为在云化架构下公司内部当前运维的定位是什么？与研发如何协同？

定位应该是平台和框架的制定者、系统的维护者。参与到系统架构设计的评审工作中，并站在系统稳定性的角度对于架构提出自己的意见，制定维护好通用的平台和框架，并监督研发落地。

3.谈谈你对SRE七层能力集的理解及应用？

所谓七层能力集就是：监控、应急事件处理、事后总结/问题根源分析、测试发布、容量规划、软件开发、产品设计；又叫服务可靠度层级模型。这个模型对于我们做稳定性维护有重大的实践意义，掌握了服务的可靠度层级模型就相当于有了稳定性保障的检查清单，以前段时间公司内部出现的一个redis相关的故障为例：首先思考redis有没有做监控，这个监控并不是简单的探活监控，而是依托于四个黄金指标的监控，监控有没有到位？然后思考应急事件处理，当出现问题的时候，我们有没有一个已经制定好的应急举措应对？事后总结与问题根源分析这次有没有分析到位？这个问题我们能不能在测试的时候发现，比如说完善一下测试环节，加强一下压力测试？能不能在发布时候将不符合要求的服务配置做好拦截，不让问题进入生产？有没有提前做好容量规划，服务和组件的水位在哪里？在软件的研发过程中有没有遵循标准的流程，从而在本地研发单测的时候就避免掉这个问题?我们针对redis这个组件有没有做相应的标准化框架与使用说明？当做完上述的事情之后，相信下一次就不会出现类似的问题了！

4.您认为一名合格ONCALL应该具备哪些能力，如何能成长为一名合格ONCALL并承担其责任？

ONCALL应该具备能够独立快速的处理解决系统的各种问题或者可以精准的将问题调度到指定的人员身上，并且确保其可以在指定的时间内完成问题的处理和解决。

要想称为合格的ONCALL首先需要对自己要维护的系统的整体架构有详细的了解，熟悉系统的架构、系统的组件、系统所承担的核心业务、核心业务的调用链路、系统的部署位置，其次是要熟练掌握问题排查和自动化处理的工具，然后是多进行反向工程，多思考问题本质，在成长的过程通过老带新的方式真正介入到问题处理中，通过实战，慢慢的以战养战，就可以成长为一名合格的ONCALL。

5.作为一名技术人员，您认为如何更好地解决架构与质量问题，降低团队OPS工作量，更好的贯彻技术栈？

        首先是对于公司内部的平台和框架要坚定不移的去贯彻去落实，不要内心有抵触心里，认为这个是加的镣铐和束缚。其次是在这个过程中如果碰到问题或者对于平台和框架有不同意见的时候要及时反馈，共同将其变得更好。

        拥有了一个统一的良好的技术栈，才有了解决架构和质量问题的前提，在此基础上，并将其嵌入到整体的系统上线流程，提供统一的运维能力，自然可以降低团队的OPS工作量。

        良好的技术栈贴近一线业务，不盲目迷信新或热的技术能力，遵守公司要求规范积极正面解决在业务和维护上遇到的问题，拥有完善的知识文档和知识共享机制，简略并且便于查找，重复问题方便定位统一解决。

        通过确立SRE团队，用引导加强制的手段，就可以将技术栈的统一嵌入到整体的系统上线流程中，从监控、应急事件处理、事后总结、问题根源分析、测试发布等提供界面化自动化工具，降低OPS工作量。

6.谈谈你对公共组件或基础服务的思考（如DNS、定时任务管理、公共锁服务等）？

正如上述回答所提到的，SRE需要把握住平台与框架。

访问公共组件的标准化框架是SRE团队的重点，因为通过对于这些标准化框架的制定和使用，可以将故障扼杀在发生之前，当研发使用这些标准化的框架去访问公共组件的时候，框架就会针对可观测性、稳定性做一系列的工作，这些工作不需要研发考虑，研发只需要遵循框架的说明书去使用框架就可以稳定高效的去使用这些公共组件。

提供公共服务也是降低运维压力和成本的有效手段，当业务使用我们的公共服务后，SRE团队接手系统维护会更快，因为它少了很多的认知负担，减少了SRE团队在服务交接时的评估和认证工作，同时仍然能保持对服务产品质量的高标准要求。这里的公共服务个人理解并非仅仅是定时任务管理、DNS这些，还有负载抛弃、过载保护、自动化、流量管理、日志和监控，当这些公共服务整合到一起的时候，那么这就是“平台”，一个SRE人员使用的SRE平台，这个平台为稳定性保驾护航。

7.谈谈你对数据平台的监控，任务管理，数据一致性的思考？

这一点首先需要把握监控重点：数据的可用性，在实现数据在指定的时间段是可用的这个目标的前提下，通过关注具体的目标，而不是具体的手段，因为手段都是为了这个目标而服务的，缩减监控的指标，把握进出口，避免落入“过程全成功，系统仍然存在故障”的尴尬情况。

数据一致性的保障，首先是明确CAP的概念，因为这个本质上是在解决一个分布式事务的一致性问题，一般的解决方案有2PC两段式提交，TCC三段式提交，事务消息。通过牺牲掉强一致性，来保证最终一致性。

任务管理这块应该是指定是定时任务调度，个人推荐选用开源的XXL-JOB。

8.如何处理你现在所在SRE团队琐事太多，员工流失等问题？

首先是明确两点，第一：管理类的杂务（团队会议、目标建立评估、问题总结报告、员工内部权限流程配置等）是必须做的，是流程开销，不是琐事。

第二：具有长期价值的脏活累活，比如告警压降优化，隐患的排查治理等不是琐事。

如果排除了上面两项的话，你还有很多事项的话，那基本上就是日常应对式、突发性的不可重复的事情了，比如说处理一个你之前从来没有碰到过的告警，处理一个你之前从来没有碰到过的用户的一个支撑诉求等等，但是如果SRE团队落地有标准的运维手册，并且针对标准的运维动作有自动化或者半自动化的话，这样的琐事就会减少很多。

并非是琐事太多造成了员工流失，而是员工自身在这些琐事中发现不到自己的实现价值，这个时候需要领导者去刻意的引导，因为每一批同类型的琐事都是一个潜在的自动化需求，相信将这个实现不仅可以给员工个人带来成就感，而且可以给整个团队乃至公司带来价值。所以说如果排除了上面我提的两点之后，你的团队还是琐事很多，那么你就偷着乐吧，你的团队大有可为！