最近看了一本书《SRE google运维解密》，由自己所在团队使命出发，来看这本书确实能够获得不少共鸣。
SRE（site reliability engineering）是专注于整个软件系统的生命周期管理，使用计算机科学和软件工程手段来设计和研发大型/分布式计算机软件系统。因此SRE专注于对其负责的软件系统架构设计，运维流程的不断优化，让这些大型软件系统运行的更可靠，扩展性更好，能够更有效的利用资源。但是并不是无止境的追求完美，当一个系统已经“足够可靠”的时候，（我们平常说的SLA几个9），SRE需要将精力转而投入到研发新的功能和创造新的产品中。
Google SRE代表了对行业现存管理大型复杂服务的最佳实践的一个重要突破。有一个简单的想法“我是一名软件工程师，这是我如何来应付重复劳动的办法”而生，SRE模型已经发展成为一套指导思想，一套方法论，一套激励方法和一个拥有广阔空间的独立职业。
现在的工程师基本上都要求有三种思维：产品思维，技术思维，工程思维。产品思维顾名思义需要从产品市场和用户的角度来分析思考，充分挖掘产品需求价值，接入终端用户，形成数据闭环，多运用减法，而不是功能的随意叠加。技术思维的源头是需求，充分理解需求，并拥抱变化，保持对新技术的敏感度，而不是为了按时出现赶工，拒绝变化引发一地鸡毛。工程思维的源头是流程，确保流程和工程师的工作环境无缝衔接，“无缝”体现于流程中的概念与工程师群体已建立的专业常识相一致、没有增加毫无价值的负担，根本仍是确保易用性。很直接的做法就是形成一套规范或者机制。产品质量直接决定了工程师的工作和生活幸福感。为了让产品的质量做到可靠，单元测试、静态分析、动态分析等确保工程质量的手段应成为工程师的基本 工作内容，通过将这些手段与CI流程进行整合去持续构建起对软件产品的质量信心。同时还需要注意风险可控，以及成本（软硬件成本，甚至部分人力成本）。
屏幕快照 2019-11-19 21.44.47.png
Google的解决之道，SRE需要对重复性，手工性的操作有天然的排斥感，需要有足够的技术能力快速开发出软件系统以替代手工操作。同时还需要和传统的运维工作区别开来，设立50%的上限。google的经验法则就是团队必须将50%的经历花在真实的开发工作中。不管对个人还是团队来说都是有益的。我们需要将流程不断优化，将简单的，易错的，经常需要做的事情自动化。一方面可以避免人为出错，带来损失。另一方面解放自己，脱离枯燥的单一工作。
网友评论