[广告前端] Node服务资源治理 - 网站源码_资源分享

服务项目环境治理

整天都在讲的服务项目环境治理，指的是什么？都包涵四方面呢？为什么要须要服务项目环境治理呢？

服务项目环境治理的最终目标

对于任何一个商品或是机能来说，合作开发完成不管怎样开始，前面还会有极短一两年的保护期。

上图是一个很基础的商品或是机能的开发周期性左图，从图中他们能看到：

机能测试阶段的生产成本非常显性，但机能保护期，包涵了商品机能插值和先期的保护，显性生产成本常常会更高。机能测试阶段时间虽然有可能十分钟（相对保护期来说），但是它是终点，也是根源。在机能合作开发期的“恶行”，很大程度上决定了先期机能保护付出。

但，以网络为媒介的商品或是服务项目常常还会要求 24 半小时无间断服务项目。这就导致了机能合作开发与保护的边界线变得不再所以明晰，尤其是 Web 服务项目，还不像应用程序那样有著一般来说的发版周期性，有时他们每天单厢正式发布捷伊版，和定期的 Hot Fix，甚至频密的 “Hot Featrue”

而服务项目环境治理的核心最终目标，除了应用软件环境治理（怎样让众多的应用软件一起熟络朝夕相处，感觉好像自己独占着力学的Xen）外，更重要的是考虑怎样能够真正努力做到 24 半小时无间断的服务项目。

服务项目环境治理包涵什么样部份

服务项目环境治理这个专业领域很笼统，能包涵以下部份：

正式发布、升级换代与版管理笔记、监视与报案天然资源与耗电量服务项目发现网络流量运维网络连接保护机械故障应急、机械故障摸查与根因分析可Vertus

现实生活当今世界的复杂程度

服务项目环境治理的最终目标，是保证应用软件提供 24 半小时无间断服务项目。服务项目环境治理没简约的抽象化问题数学模型，他们须要面对的是现实生活当今世界的复杂程度。

服务项目环境治理它并没所以简单单纯，在平庸情况下，他们应该尽量所有机械故障的恢复，但机械故障的可能太多，很多情况是他们无法提前预知的，这也就意味着人工介入并不能比避免。

所以，网络不只是产生了合作开发工程师的工种，随着系统变得更加复杂，怎样让应用软件提供 24 半小时无间断提供服务项目呢？

Site Reliability Engineer (网站可靠性工程师)，最先被 Google 引入，后被各类公司所借鉴。区别于传统意义上的运维，SRE 也是一个特殊的工程师群体，和服务项目端合作开发一样，他们肩负着自己独特的使命。

他们先来看看机械故障的类别，和 SRE 独特的使命又是什么。

可用性时间表

他们系统的可用性能努力做到 “三个9”、“三个9一个5”，甚至更高的“四个9”，但常常不可能努力做到系统 100% 可用，即没可能，也无必要。

这个对于非技术同学可能会比较难以理解

他们能按照下面这个表去更加具体化他们的不可用时间，比如：

“三个 9” 等价于平均每年可宕机 8.76 半小时，平均每月宕机时间为 43.2 分钟。

“四个 9” 等价于平均每年可宕机 52.6 分钟，平均每月宕机时间为 4.32 分钟。

机械故障类别

机械故障基本上是难以避免的。能导致机械故障的因素又很多，大体上能按照这么几个层面进行划分：

软硬件升级换代和各类配置的变更。变更是机械故障的第一问题根源。所以，这是一个研发效率与稳定性之间做平衡的问题（一个可用的思路是引入错误预算，详见：Motivation for Error Budgets）。软硬件环境机械故障引发的服务项目异常单机机械故障：硬盘坏、内存坏、网卡坏、系统死机失去响应、重启等机房或是机架机械故障：断网、掉电等区域性机械故障：运营商网络机械故障、DNS 服务项目机械故障、海底光缆损坏等自然灾害：地震、火灾、山洪等

3. 终端用户的请求

秒杀场景，短时间大量用户涌入，系统承受能力超出规划针对性恶意攻击特定类型用户请求占用大量服务项目端天然资源

SRE “独特”的使命

保证服务项目 24 半小时无间断的运行，必然有一系列复杂的系统性问题须要处理。而在服务项目越来越复杂的今天，传统的的运维工程师已经比较难满足需求。SRE 这样的职业也就应运而生了。

DevOps 还是 SRE?

DevOps 这个名词是在 2008 年末流行起来的，截止到本书写作时（2016 年初），这个单词的具体意义仍在不断改变中。这个名词的核心思想是尽早将 IT 相关的技术与商品设计和合作开发过程结合起来，着重强调自动化而不是人工操作，和利用应用软件和工程手段执行运维任务等。这些思想与许多 SRE 的核心思想和实践经验相符合。他们能认为 DevOps 是 SRE 核心理念的普适版，能用于更广范围内的组织结构、管理结构和人员安排。同时，SRE 是 DevOps 数学模型在 Google 的具体实践，带有一些特别的拓展。

——《SRE Google运维解密》 P6

或是用下面这句伪代码概括：

class SRE implements DevOps

一般来说，SRE 团队要承担以下几类职责：

可用性改进延迟优化性能优化效率优化变更管理监视应急事务处理耗电量规划与管理

琐事与怎样减少琐事

在这些复杂的工作中，有包涵了大量的“琐事”。那什么是琐事呢？

琐事指的是运维工作中手动性的，重复性的，能被自动化的，战术性，没持久价值的工作。而且，琐事与服务项目呈线性增长。并不是所有琐事都有上面的全部特性，但，每件琐事单厢满足以上述的一个或是全部的属性。

SRE 的一个公开最终目标就是要保证每个 SRE 的工作时间中运维工作（琐事）的比例低于 50%。SRE至少要花费 50% 的时间在工程项目上，以减少未来的琐事或是增加服务项目机能。增加服务项目机能包括提高可靠性、性能，或是利用率，同时也会进一步消除琐事。

琐事的危害

职业停滞士气低落

另外，牺牲工程实践而做琐事会对 SRE 组织的整体发展造成损害，原因如下：

造成误解进展缓慢开创先例促使摩擦产生违反承诺

什么算工程性工作

工程工作是一种新颖的、本质上须要主观判断的工作。它是符合长期战略的，会对你的服务项目进行长久的改善工作。工程工作通常是有创新性和创造性的，着重通过设计会解决问题，解决方案越通用越好。工程工作有助于该团队或是整个 SRE 组织在维持同等人员配备的情况下接手更大或是更多的服务项目。

典型的 SRE 活动

典型的 SRE 活动分为以下几类：

应用软件工程：编写或是修改代码，和所有其他相关的设计和文档工作，例如: 编写自动化脚本创造工具或框架增加可拓展性和可靠性的服务项目机能修改基础设施代码使其更加稳健

2. 系统工程：配置生产系统、修改现有配置，或是使用一种通过一次性工作产生持久的改进的方法来书写系统文档。

监视的部署和更新负载均衡的配置服务项目器配置操作系统的参数调整和负载均衡器的部署与研发团队进行架构、设计和生产环境方面的咨询工作

3. 琐事：与运维服务项目相关的重复性的，手动的劳动

4. 流程负担：与运维服务项目不直接相关的行政工作

招聘人力天然资源书面工作团队 / 公司会议任务系统的定期清理工作工作总结同行评价和自我评价培训课程等

番外：Google 也翻车

www.google.com/appsstatus#…

在 12 月 24 日晚上 7 点到 9 点间，Google 由于云端运算服务项目耗电量分配出现问题，导致账号服务项目不可用，进而影响全系 Google 服务项目的使用。

期间，出现了类似“VPN 团队因为无法连接 VPN，而导致 VPN 问题无法被及时修复”的问题。

本次宕机是本年 Google 第三次宕机事件，有些工程师已经其宣称信仰已经崩溃。

服务项目类型&&天然资源视角

从他们目前的服务项目类型和业务现状来说的话，目前他们负责的的服务项目主要会运行在 TCE 、ByteFaaS 这些云计算平台上。

随着业务的发展，目前他们后端团队已经逐渐开始承接 BFF（Backend For FrontEnd）服务项目合作开发的工作，主要涉及后端 RPC 接口的数据聚合、裁剪等内容，还会承接一部份和后端 UI 关系比较紧密的业务逻辑。在这种场景下，他们不须要直接连接数据库。对内服务项目中，Node 已经承担起了相当一部份业务系统的后端合作开发，Node 在他们团队中发挥着越来越重要的作用。

务能够正确使用天然资源，降低风险，提高系统稳定性。

计算服务项目多机房部署

测试阶段要进行多机房部署

在上面服务环境治理简要介绍部份他们提到过，服务项目环境治理的最终目标就是让他们的服务项目 7* 24 半小时运行，所以这就对他们的实例数量有著一定的要求。

他们推荐根据服务项目的状态留有一定的余量，如 N+1 或是 N+2，或是其他业务上规划好的值。这部份就涉及到了耗电量预估，比较复杂，同样有著很多须要考虑的点，有著“现实生活当今世界的复杂程度”。目前业界已经有公司在用 AI 帮助业务进行耗电量的规划与预测。

网络连接&&耗电量规划

在上面他们提到过，机械故障类型大体分为三种：

软硬件升级换代和各类配置变更软硬件环境的机械故障终端用户的请求

“网络连接”就是一种典型的由“终端用户请求”导致的机械故障。所以，它的原因是什么？

网络连接原因

所谓网络连接，最直白的理解就是当消耗超过了天然资源的承载能力，导致天然资源耗尽，进而出现了系统的网络连接。所以网络连接从本质上讲，能归为耗电量规划问题。

天然资源消耗光了，通常的原因有以下几种：

用户增长过快（自然 && 活动引流），天然资源规划的预期没跟上部份天然资源机械故障，导致线上可用天然资源不足。比如双机房容灾场景系统关键天然资源负载变低。随着时间的推移，数据库中的数据越来越多，达到了某个临界点后，数据库的整体延迟增加，支持的并发度也下降了不合理的重试逻辑比如一个 API 失败了后重试 3 次，然后 API 内部依赖了一个下游服务项目提供的 API，同样可能会重试 3 次，所以可能的额外重试次数就是 3～9 次，如果依赖链路够长的话，重试次数会指数级别上升。

网络连接后果

通常网络连接的表现是“天然资源耗尽”。而且通常也会有“连锁反应”，定位比较困难。更可怕的事情长期网络连接产生的正反馈效应。比如线上一共 10 个实例，网络连接导致其中 2 个实例宕机。然后剩下的 8 个实例压力会更大。这种由于正反馈循环导致恶化的情况，在短时间内就快速形成了雪崩效应，击垮系统。

当宕机实例重启后，又会被迅速打垮，形成一种“在棺材里做仰卧起坐”的现象，直到整个服务项目全部挂掉。

怎样应对？

降低网络连接发生概率即使发生网络连接，杜绝雪崩效应

服务项目端处理方式

应该在网络连接情况下主动拒绝请求，保护自己不进入网络连接崩溃状态。及早将请求标记为失败，尽快返回。伴随性能测试进行耗电量规划，确定服务项目耗电量。可根据服务项目实际的重要冗余部份天然资源服务项目优雅降级。优雅降级不应该被频频触发，否则就是耗电量规划上的失误。

应用程序的处理方式

重试限制每个请求重试次数使用随机化、指数递增的重试周期性考虑使用全局重试预算。例如每个进程每分钟只允许重试 60 次。如果重试预算耗尽，所以就直接把请求标记为失败，不要发送给服务项目端。

2. 请求重要性级别，例如“可丢弃”、“一般”、“重要”、“非常重要”，当发生服务项目端网络连接后，根据请求级别抛弃一定的请求，直到系统负荷正常

3. 请求延迟和截止时间。结构性的超长时间请求有可能拖垮系统，并引起服务项目的雪崩效应。如果请求处理分为多阶段，则每阶段前都检查下截止时间，发现超时及早返回。

4. 应用程序节流。当应用程序在发现最近请求错误中有大部份是由