Google SRE读后感 《SRE Google运维解密》一书由Google SRE团队各成员所写的短文组成，书中记载了SRE团队在支持Google业务规模不断扩大的过程中所总结的经验以及实际案例。即使在IT行业发生翻天覆地变化的今天，此书仍然弥足珍贵，它详细记录了Google迈过分水岭时期的全过程。很显然，这些经历没有办法完全复制，也许只能被模仿，但是却可以启发读者，指引未来。 本书分为以下4部分： 1. 概述——了解SRE的定义，以及该职位与传统IT行业运维职位的不同 2. 指导思想——详细讨论SRE的工作模式、行事方式，以及日常运维工作中关注的焦点 3. 具体实践——理解SRE日常工作背后的理念，讨论具体的构建与运维大型分布式系统的实践 4. 管理——探索Google在培训、内部沟通，以及会议方面的最佳实践 一、概述 什么是SRE？在Google没有“运维”这个职位，只有SRE团队（Site Reliability Engineering）。SRE团队主要由两部分人组成，一部分是全职开发人员，另外一部分人需要掌握两方面的技能，95%的开发技能和5%的运维思想、技能；同时所有人都必须非常愿意、也非常相信用软件工程方法可以解决复杂的运维问题。这样组成的团队具有以下特点：对于重复性、手动性的操作有天然的排斥感；有足够的技术能力快速开发出软件系统以替代手工操作。 二、指导思想 DevOps还是SRE？……

背景 由于容器化和微服务的大力发展，Kubernetes基本已经统一了容器管理方案，当我们使用Kubernetes来进行容器化管理的时候，全面监控Kubernetes也就成了我们第一个需要探索的问题。我们需要监控kubernetes的ingress、service、deployment、pod……等等服务，以达到随时掌握Kubernetes集群的内部状况。 此文章也是Prometheus监控系列的第三篇，具体描述了在Kubernetes中使用Prometheus来采集业务指标。多数为思想指导，会列出两个例子。第一个例子是针对部署在Kubernetes中的服务，另外一个例子是非Kubernetes部署的服务。前者为使用“动态采集”，后者使用“静态采集”。 概念 要使用Prometheus实现自动采集业务指标数据真的非常简单，只需要2步 1、业务侧实现一个接口，返回Prometheus规范化数据，如下： traefik_entrypoint_requests_total{code="302",entrypoint="https",method="HEAD",protocol="http"} 1 traefik_entrypoint_requests_total{code="302",entrypoint="https",method="POST",protocol="http"} 1 traefik_entrypoint_requests_total{code="304",entrypoint="http",method="GET",protocol="http"} 15 traefik_entrypoint_requests_total{code="304",entrypoint="https",method="GET",protocol="http"} 5951 traefik_entrypoint_requests_total{code="400",entrypoint="https",method="GET",protocol="http"} 149 traefik_entrypoint_requests_total{code="403",entrypoint="http",method="GET",protocol="http"} 2 traefik_entrypoint_requests_total{code="403",entrypoint="https",method="HEAD",protocol="http"} 2 traefik_entrypoint_requests_total{code="404",entrypoint="http",method="GET",protocol="http"} 680 traefik_entrypoint_requests_total{code="404",entrypoint="http",method="HEAD",protocol="http"} 15 traefik_entrypoint_requests_total{code="404",entrypoint="http",method="POST",protocol="http"} 674 每行代表一个监控项，以KEY VALUE形式返回，KEY可以带上0个或多个属性，多个属性以 “，”分隔。在Prometheus中查询数据的时候，可以用这些属性作为筛选条件。 Key中不能包含 “-” 等特殊字符，最好使用 “_” 。 2、运维侧部署的时候，在svc上带上3个标签……

背景 由于容器化和微服务的大力发展，Kubernetes基本已经统一了容器管理方案，当我们使用Kubernetes来进行容器化管理的时候，全面监控Kubernetes也就成了我们第一个需要探索的问题。我们需要监控kubernetes的ingress、service、deployment、pod……等等服务，已达到随时掌握Kubernetes集群的内部状况。 此文章是Prometheus监控系列的第二篇，基于上一篇讲解了怎么对Kubernetes集群实施Prometheus监控。 Prometheus部署 在k8s上部署Prometheus十分简单，下面给的例子中将Prometheus部署到prometheus命名空间。 部署——监控数据采集 Prometheus 将kube-state-metrics和prometheus分开部署，先部署prometheus。 prometheus-rbac.yaml apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRole metadata: name: prometheus rules: - apiGroups: [""] resources: - nodes - nodes/proxy - services - endpoints - pods verbs: ["get", "list", "watch"] - apiGroups: - extensions resources: - ingresses verbs: ["get", "list", "watch"] - nonResourceURLs: ["/metrics"] verbs: ["get"] --- apiVersion: v1 kind: ServiceAccount metadata: name: prometheus namespace: prometheus --- apiVersion: rbac.……

背景 由于容器化和微服务的大力发展，Kubernetes基本已经统一了容器管理方案，当我们使用Kubernetes来进行容器化管理的时候，全面监控Kubernetes也就成了我们第一个需要探索的问题。我们需要监控kubernetes的ingress、service、deployment、pod……等等服务，已达到随时掌握Kubernetes集群的内部状况。 此文章是Prometheus监控系列的第一篇，目的也很明确，旨在于寻找一套能够胜任kubernetes集群监控的架构。 k8s监控方案调研 1、cAdvisor + InfluxDB + Grafana 2、Heapster + InfluxDB + Grafana [x] 3、Promethus + kube-state-metrics + Grafana……

莎士比亚搜索服务 新韵文+过载事故：2015-10-21 （沟通负责人会随时更新事故概要） 摘要 莎士比亚搜索服务由于新发现的韵文不在索引中而处于连锁故障状态 状态 活跃，事故编号 ##45 事故处理中心 IRC #shakespeare 频道 事故处理组织架构：（参与人） 目前事故负责人：xxx 运维负责人： 计划负责人： 沟通负责人： 下一个事故总负责人：待定 （沟通负责人在交接班时或者每4小时更新一次）……

莎士比亚新询文事故总结（事故编号 #465） 日期 2015-10-21 作者 Jennifer、martym、agoogler 目前状态 已经终稿，待办事项正在进行中 摘要 莎士比亚搜索服务出现66分钟的故障，由于新发现了一篇韵文，导致用户流量暴涨。 事故影响 预计12.1亿个请求丢失，没有损失任何收入。 根源问题 由于异常的高负债情况以及搜索词语在 Shakespeare Corpus 中不存在时的一项资源泄露导致的连锁故障的发生，新发现的韵文使用了一个之前从未在莎士比亚文献中出现的词语。这恰恰是用户大量搜索的关键词！在日常情况下。这种资源泄露导致的任务崩溃现象，由于出现非常不频繁，而没有被注意到。 触发条件 潜伏性的Bug被大量上涨流量所触发……

日期 2015-10-23 参与者 agoogler、clarac、docbrown、jennifer和martym 公告 大型事故（#465），造成错误预算耗尽 之前的待办事项评审 确保山羊传送器可以用于传送牛奶 ——质子加速中的非线性特质可以预知了，应该可以在几天内解决准确性问题 事故回顾 新韵文的发现（事故465） —— 12.1亿个请求在连锁故障与潜伏先bug的共同作用下丢失，索引中不存在新的韵文和未预料的流量……

概念

Ingress是kubernetes1.1之后官方提出的一个标准，按照这套标准它有多种实现，比如 nginx-ingress-controller、traefik-ingress-controller、kong-ingress-controller，这3中都是官方推荐的。Ingress的出现解决了Service的短板：只能在tcp层面做负载均衡。而ingress可以方便的做http/https层面的负载均衡。一个是在4层，一个在7层。ingress就是控制客户端从入口连接到k8s集群服务的规则的集合！

ingress出现之前，服务暴露是这样的：

ingress出现之后，服务暴露是这样的：

……

什么是 Let’s Encrypt Let’s Encrypt 是国外一个公共的免费 SSL 项目，由 Linux 基金会托管。它的来头不小，由 Mozilla、思科、Akamai、IdenTrust 和 EFF 等组织发起，目的就是向网站自动签发和管理免费证书。以便加速互联网由 HTTP 过渡到 HTTPS，目前 Facebook 等大公司开始加入赞助行列。……