关于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