0。SRE为什么诞生？原因一：企业成本的增长与用户的增长不成线性变化。但是随着系统复杂度的增加，组件越来越多，用户的流量压力也越来越大，相关的变更也会越来越多，模块之间的变更顺序也会越来越复杂。在这种情况下，单纯依靠增加运维人力已经不能满足业务的发展需求，反而会增加企业的成本；原因二：传统的研发团队和运维团队天然存在矛盾。公司IT人员配置：研发（Dev）和运维（Ops）。研发部专注于快速构建和快速发布；运维部门关注的是如何避免故障，这在目标上是矛盾的。而且随着IT技术的发展，对IT从业人员的要求也越来越高。他们不仅要了解底层系统，还要了解数据算法。同时，他们必须快速追赶主流技术。能满足这种要求的人才太少；三：生产工具是适应生产力发展的必然产物。为了提高IT行业的整体效率和质量，人工运维时代逐渐过渡到脚本工具运维，然后是平台数据运维，再到平台软件运维，再到智能化自动化运维。通过一系列手段、工具、理念的推进，Ops技术将发展为DevOps、DataOps、AIOps等；1.什么是SRE？1.1对SRE的基本认识那么和研发同学、运维同学不同的是，SRE到底要做什么样的工作，应该具备什么样的能力？Google试图解决Dev和Ops之间的矛盾，聘请软件工程师，创建软件系统来维护系统运行，以取代传统运维模式中的人工操作。SRE团队和产品开发部分在学术和工作背景上非常相似。从本质上讲，SRE就是用软件工程的思想和方法论来完成以前由系统管理员团队手动完成的任务。Google的SRE究竟要负责什么？SRE不负责在Google启动和部署某项服务。SRE主要负责保证服务的可靠性和性能。同时负责数据中的资源分配，为重要服务预留资源。SRE不负责某个业务逻辑的具体编写。主要负责在出现服务宕机等紧急情况时快速响应，尽快恢复服务，减少服务中断造成的损失。SRE的日常任务和职责是什么总的来说，SRE团队有以下几类职责：可用性提升、延迟优化、性能优化、效率优化、变更管理、监控、紧急事务处理、容量规划和管理。工具不要创造可靠性。人类有。但是工具可以提供帮助。SRE的使命是从可用性和性能的角度提升用户体验，同时减少资源消耗。运维不应成为SRE任务的一部分。运营是理解生产的一种方式。1.2SRE的技能栈语言和工程实现深入即时开发语言（Java/Golang等）业务部门使用开发框架并发、多线程和锁资源模型理解：网络、内存、CPU故障处理能力（分析瓶颈，熟悉相关工具，还原场景，提供解决方案）通用业务设计方案，多种并发模型，及相关各种底层数据库和存储系统的Scalable设计特性和优化问题定位工具容量管理Tracing链接trackingMetrics测量工具Logging日志系统运维架构能力Linux熟练，了解Linux负载模型，资源模型熟悉常规中间件（MySQL，Nginx，Redis，Mongo，ZooKeeper等），能够调优Linux网络调优，网络调优IO模型与资源编排的实现关于系统（Mesos/Kubernetes）理论的语言。机器学习中的相关理论和典型算法。熟悉分布式理论（Paxos/Raft/BigTable/MapReduce/Spanner等），能够针对场景决定合适的解决方案资源模型（如排队论、负载方案、雪崩问题）资源编排系统（Mesos/Kubernetes）2、SRE是如何解决问题的？2.1中台系统与应用解耦研发同学负责生产环境，SRE负责组件或集群的可服务性和稳定性。大多数SRE工程师都是标准的软件工程师。他们擅长用系统工程的方法解决基本问题。系统中的问题持续解决，工程化，使得运维压力不会随着上层应用的增加而线性增加（通常一个20人的SRE团队可以支撑上千研发同学的应用开发).同时，SRE同学对Unix系统内部细节和1-3层网络有很好的理解，可以和研发一起分析应用性能问题。SRE应该更好地管理系统元数据。系统元数据应该是系统架构拓扑图。通过动态准确更新元数据，将采集到的Event、Message、Metric等数据映射到真实环境中。并且可以通过多种方式诊断系统的健康状况，使自动化监控和管理成为可能。SRE通过稳定性进行抽象，可以解决一般的稳定性问题。为了提高庞大系统的运行效率，需要不断优化系统中的热点，将系统中的热点服务扩展、升级、重构为模块化的系统。Service，这也是SRE中对系统进行解耦的方法。不仅如此，SRE将每个服务的可用性定义标准化，对不同的服务应用统一的标准，将稳定性作为每个服务的重要衡量指标。通过以上操作，收集服务治理问题，系统健壮。性别。2.2明确服务之间的可用性依赖关系2.2.1面向SLO的编程标准的实现对于SLO，下面举个例子来说明，为什么要有SLO，设置SLO有什么好处？对于客户来说，是可预测的服务质量，可以简化客户的系统设计对于服务提供商来说，是可预测的服务质量更好的成本/收益权衡更好的风险控制（当资源有限时）失败更快地响应并采取正确的措施定义SLO是一件相当复杂的事情。这种使用往往与用户体验直接相关。推荐一个实际案例来扩展如何自定义自己服务的SLO。（案例研究：为新服务实施SLO-https://www.usenix.org/conference/srecon19americas/presentation/lawson）推荐一篇解释如何为请求延迟指定SLO的文章。详情请参考链接《Latency SLOs Done Right》https://www.usenix.org/sites/default/files/conference/protected-files/srecon19apac_schlossnagle_latency_slides.pdf推荐一篇文章，从请求解释如何制定一些核型系统运行期间的SLO，《How to trade off server utilization and tail latency》https://www.usenix.org/sites/default/files/conference/protected-files/srecon19apac_slides_plenz.pdf2.2.2为SLO监控设计SLO以结果为导向的警报，而非以原因为导向的警报四大黄金信号服务不可用或访问速度变慢时，往往会影响产品的整体质量。目前已知的基本监测指标有数百种。通常的做法是在这些指标中选择平台或业务比较关注的指标。监控和警报；Google的站点可靠性工程师(SRE)团队定义了四个需要监控的关键指标。他们称之为“四个黄金信号”：延迟、流量、错误和饱和。这四个信号应该是服务级别中非常关键的部分，因为它们对于提供高可用性服务至关重要。如何定义高质量监控：明确业务服务的SLO（应与业务提供给客户的期望一致），并用合理的SLI来描述；如盘点信息（总量、成功量）、计量信息（同比、环比）；主观上，监控要有丰富的内部状态数据和高可观测性条件；客观上要有业务视角，能够快速定位是全局问题还是局部问题；系统本身的健壮性不会因局部问题影响监控的权威性；有能力限制配额以防止容量问题；告警清理和定时规则优化，定时清点告警，优化不影响SLO的规则；2.3完整的场景化钻井自动化系统建设除了考虑系统的能力外，还必须考虑人所发挥的重要作用。毕竟，一旦有些突发事件必须由人来处理，那么此刻人的稳定性和准确性也是需要得到保证的。.微软在SRE大会上提出了一个有趣的观点：如果一个系统可以比人类做得更好，那么人类应该知道如何监控系统本身。因此，在保证SLO的情况下，可以做一些攻防演练（关闭SRE系统UI后，SRE应该如何操作？）；或建立一个模拟系统供人们执行该系统；3.SRE观察3.1SRECONF2019门户网站SRE2019观察：会议报告：SRECONAMERICAS2019:https://noidea.dog/blog/srecon-americas-2019会议日程：SRECONAsia/Pacific2019:https://www.usenix.org/conference/srecon19asia/program3.2系统的可观察性要多注意的几点，换句话说，你真的了解你的系统吗？你真的了解你的应用吗？（不仅是后台系统，还有一些移动系统和应用）需要从Logs中获取更多的知识，挖掘出更多的内容供SRE使用。随着可观测性需求的不断提出，灵活新颖的可视化工具越来越被大家所认可。仅仅使用折线图来可视化指标是远远不够的。需要更新颖、更方便的可视化解决方案；同时，必须生成数据。价值，而不是简单的可视化，越来越多的公司使用Pipeline来解决相关任务的创建和管理，让数据清洗和组织成为更好的价值，让算法发挥最大的效用。SRE不仅要发现系统中的热点，还要快速解决这些热点，并在未来的架构演进中杜绝此类问题，所以系统的自愈能力应该成为每个公司都关心的问题。
