关于Google SRE工程师

  今天下午，本身从新思考了一些SRE(Site Reliability Engineering)，略谈谈SRE的相关概念与自身实践。

  相信你们可能不多或则没有听过SRE这个名词，我会简单的分析一下关于SRE工程师，固然，这仅仅是让你们对SRE有一个初略的概念性理解，若是须要有更深刻的理解, 请你们去看<<Google运维解密>> 或官网  landing.google.com/sre/​

landing.google.com

什么是SRE工程师

  提到SRE工程师，必须得先提到运维工程师，我从运维这个角度切入到SRE。你们对运维工程师的认识应该会普遍，一提到运维工程师脑海里都是系统管理员，网管等标签，也会认为工做也是低效重复，技术含量相对较低，在公司里地位也会偏低，能够说相对最苦逼了，其实真实状况大体也如此。最近几年devops比较火，devops给运维带来了新的活力和更大的空间，用程序去自动化一部分系统，可能会包括自动化代码构建，部署流程，相关系统软件安装，监控，告警等一些自动化工做，这个level看起来会更高一些，也能解决系统大多数重复工做。不过在该模式下，在公司服务到必定规模，或高速发展中，想继续保持效率和保证服务高SLA，须要招聘更多人去作系统的维护与系统研发。在同事的引荐下，看到<<Google运维解密>>，里边介绍了Google提出的概念SRE, 并讲述了Goole在运维复杂系统中的运维实践，也提供了一些新的运维方法论，用程序去自动化整个系统，工程师直接参与研发，设计，维护，优化整个系统，而且在这个长期过程当中，总结了一些重要的方法论。

  能够看出来，在Google ‘运维'工做内容再也不有低效，重复，技术含量低的相关标签了，他们须要去有研发工程师的编码能力，比研发更深刻理解操做系统，计算机网络，数据库，甚至到架构设计等模块，相应要求也会更高。最近也看到，国内也有不少公司也在学习一些SRE的方法论，在招聘上能够看到不少SRE相关的招聘，或则是不少运维或系统架构师，devops岗位中有一些SRE的相关标签，笔者的目标方向是架构师，也会在工做中也会去学习应用SRE的一些方法论。

关于Google在SRE中实践

  为何Google会提出相似SRE相关运维概念？其实不是，国外像facebook, twitter, 国内一些大厂相信确定都有本身的运维体系，或则是软件维护服务的高可用方法论，只是Google先提出来SRE这个概念，而后其开源的文化推进它将其开源，这里不得不称赞Google以超强的实力和超前的眼光，将运维这个职业作成世界上最高端的技术工种之一,给业界提供了一种运维方法论。

Google维护着几乎全球最大的服务器集群，我只从 www.google.com 这个看似简单网页，仔细一想就能感觉到他们的系统会有多复杂，提供图片，视频，新闻，搜索全球化海量数据服务， 系统复杂度和对可用性要求都很是高，架构上须要考虑自建机房，服务部署全球化，保持服务高性能, 扩展性，可用性。基础服务来看，须要提供具备高性能，高可用，无扩展问题的基础服务，像分布式存储，分布式数据库，分布式计算引擎，分布式配置中心等服务，仅仅是www.google.com就须要考虑这些，若是加上play store, youtube, dirve, translate等其余服务了，面临的问题也会更多更难，这些一直推进着Google在运维方向的思考实践和努力。

Google怎么解决上面的问题？

a 自研相关基础服务:

  首先他们的运维工程师都是由研发组成，他们特性都是不喜欢重复，低效的工做方式，喜欢用程序去自动化系统，甚至是自治系统。

  他们的系统几乎都是自研的，并且在自研相关系统的同时，就会去考虑分布式的应用场景，考虑系统的容错性，可扩展性，运维简化等方面，这些系统有直接是SRE进行研发，也有SRE参与设计编码等。我简单列举一些他们内部服务，讲一下各自系统解决的问题。

  Borg 管理物理服务器和编排服务， 就是简化物理机管理与服务管理

  Bigtable, Spinner,GFS 提供存储基础服务,知足各类存储需求，分布式kv存储，分布式sql数    据库，分布式对象存储

  基于 openflow协议相关SDN产品 软件网络去解决大规模网络配置管理问题

  Chubby 分布式锁服务

  Borgmon 监控服务

  Grpc,Stubby服务调用

等等

b 方法论:

  光这些还不够，尽管在软件设计之初就有考虑了系统的 扩展性，简化运维，容错性等方面，不过仍是存在大量主机或基础服务须要实时管理维护, 异常管理体系。

a 标准化一些基本流程

  1 针对服务定制服务质量目标

  2 sre花费更多的时间在研发上边，更多减小杂事

  3 标准化监控系统和高效率的告警系统

  4 高效的oncall轮班

  5 事故的响应方式

  6 复盘与事故管理机制

  等等

b 解决系统性问题的方法论:

  1 前端服务器负载均衡

  2 数据中心内负载均衡

  3 应对服务过载问题，限流

  4 连锁故障的解决方式

  5 分布式共识

  6 分布式周期性任务系统

  等等

这里没有很细节的谈这些方法论的细节，相关细节可用购买 <<Google运维解密>>，或则直接上官方网站查看  landing.google.com/sre/​

本身对SRE的实践

a 参与编码或设计并优化各个系统

  我会主动去参与设计或编码一些关键的系统，如监控系统，消息系统，调度系统，文档转换，录像转换，甚至是一些web系统。这会让我对系统的理解程度会更高，更可控，同时在之后寻找系统风险，性能瓶颈会得出更好的方案。

b 拥抱开源,造成自身技术栈，标准化一些技术去解决问题

  不是每家公司都会面对google面对的问题，也不会有这么大的研发精力和这么高的标准去自研自身系统，全部从我这边来看仍是主要是去拥抱开源。

  1 kubernetes/saltstack/ansible/openstack 等解决服务器管理运维部署服务化问题

  2 elasticsearch/filebeat/logstash/kibana/flume 等解决日志收集问题

  3 prometheus/influxdb/zabbix/grafana/openfalcon 等解决监控问题

  4 jenkins/git流程 解决自动化测试与构建各个组件标准高可用方法论

  5 hadoop/ceph/swift/cinder 等解决存储问题

  mq, loadbalancer, sql等等

c 大量工做放在如何自动化，如何自治系统这边。

  最好的系统是彻底自动的，彻底不须要人干预的，也是我和公司一直努力的方向，好比设计自动化的调度系统，完成不须要人工干预管理的上千台服务器的目标。

d 时刻保持学习，总结的心态，将本身的定位放在系统工程师这个方向。

  不给本身打标签，不定义本身是如java工程师，测试工程师，python工程师，工做目标是用如何解决问题，而后自身在保持广度的同时，也要有必定领域的深刻，学习技术要知道其工做原理，优化方式，好比像最近的话是专心研究容器技术和虚拟化技术等相关技术。

最后:

  感谢Google开源其SRE的相关概念与方法论，让你们有更多思路和方式去解决系统问题。

  贴上之前对sre相关分享的ppt连接.

https://drive.google.com/file/d/1ln_vbHVHuAkoDkRAg3pXV3M8h1JTbH1X/view​ drive.google.com