大型网站运维从系统管理到SRE

港南四大炮亡

于 2024-02-25 17:11:29 发布

阅读量1k

点赞数 24

文章标签：运维数据库

本文链接：https://blog.csdn.net/lpx1249115962/article/details/136270824

版权

第1章关于SRE

SRE（网站稳定性工程师）

在SRE出来之前，运维工作主要聚焦于日常工作，如值班（On-Call），处理工单或跟进线上问题，在这个过程中运维虽然也会涉及线上自动化运维相关的代码开发，但是在执行的时候往往缺少规划和方向性。SRE相比之前对运维角色的定义，对运维进行了更深层次的角色定位。

第3章监控建设

场景一，Kafka里存储的是用户订单数据，之后的消费业务是订单处理服务。此时Kafka服务消费堆积预示着两个线上故障——订单无法及时处理、用户交易失败。这两个线上故障可能是消费服务存在异常，数据消费被阻塞；也有可能是用户请求数量超过消费服务处理容量上限，造成数据消费堆积。无论是哪种原因，监控服务都有必要在出现异常时发送报警通知运维团队。

场景二，Kafka里存储的是用户操作日志，之后的消费业务是离线日志处理服务。消费业务把Kafka当做缓存队列暂存数据，数据在Kafka内堆积符合业务预期。在这种情况下，监控服务就不应该对短时间内数据堆积情况太敏感，这种报警发送给用户是毫无意义的。

综上所述，报警准确率的提高是监控服务和运维团队合作的结果，运维团队要向监控服务表达被监控业务的特征，监控服务要将业务特征转化成各种报警能力，最终体现在提高报警准确率方面。理想的报警是要结合业务数据的实际情况，使用多种指标维度，再结合监控服务提供的各种抑制机制，最终在漏报和误报之间达到最佳平衡。

第4章变更管理

变更流程：

变更提出》Review 评审》执行变更

在所有公司，业务的稳定性都和钱有关系，业务团队通常会比较注重利用流程约束变更行为，进而规避或防止某些经常犯的错误。

第6章服务稳定性治理

6.1 SLI/SLO/SLA的制定和落地

SRE在处理稳定性时引入了SLI（服务等级指标）、SLO（服务等级目标）和SLA（服务等级协议）用于量化线上稳定性。实践发现数据化的衡量方式对服务稳定性有更精准的评估，而且也得运行的稳定性状态也更加直观和方便监控。

SLI指服务稳定性的几个关键指标。线上业务很多指标都有监控，但并不是所有指标都是关键的。

在实际工作中，不同的服务会有不同的SLI，SLI是一个复杂的过程。常见的对外服务SLI指标有以下几个方面。

1.性能指标

主要是延迟、吞吐量、处理速率（TPS/QPS）、时效性等。性能指标一般会直接和应用的性能监控数据对接。

2.可用性指标

主要是可靠性、故障时间/频率、在线时间等。可用性指标一般会基于外部的监控数据，如错误频率可以和APM应用监控数据关联。

3.质量指标

主要是准确性、正确性、完整性、覆盖率等。质量指标一般会用于衡量大数据、AI等对数据处理结果有要求的业务，一般会依赖事后数据统计监控。

SLI除可以衡量服务的外在表现外，还可以衡量线上业务活动的各个方面。例如，运维团队支持情况如果有SLO，就会有SLI，这个时候的SLI可能会是要求运维团队值班时响应需求的时间和工单处理的时效等。

每个业务的SLI都需要和业务监控数据对应，在实施时注意业务的SLI不要太多，过多的SLI会导致衡量问题困难，所以一般情况下单业务的SLI建议不要超过3个。在制定SLI是建议站在用户的角度去提炼核心指标，指提取用户最关心的几个指标。

SLO是团队努力要达成的一个质量指标，一般情况下会是业务团队承诺给用户的一个指标。当我们说一个业务的SLO指标要4个9（99.99%）时，用户就明白该业务团队做出了99.99%的可用性保障，然后整个SRE团队会以这个指标作为衡量工作绩效的标杆并努力达成这个指标。

6.1.3 SLA的计算和应用

SLA一般用于付费用户的场景，一般会具有一定的法律效力。当一个服务和用户签订SLA时，往往涉及服务付费、承诺质量和违约责任等内容。

6.4.3混沌工程

指的是一种随机在线上注入故障，用于检测线上业务健壮性的工程手段。

6.7灾备建设

1.同机房灾备

很多公司都有实施同机房灾备。例如，同一个机房做一个跨机架的数据库主备、Keepalived主从等。这些集群都有一个共同的特点：它们能容忍机房层面单机或单个机柜的故障，只要不是整个机房挂掉，基本就能保障数据和服务不出现大的问题。

2.同城双活

将业务部署到同一个城市的两个机房的方式，来降低单机房不可用的风险。

3.异地数据灾备

与金融支付相关的业务，肯定会做异地数据灾备。

4.两地三中心

两地指的是两个城市，三中心指的是三个IDC数据中心。

5.分布式多活

做到分布式多活的业务往往会在很大范围上（如在全国范围或全球范围）内进行IDC数据中心布点。

第8章容量管理

IT资源费用：

裸金属物理机、公有云资源、网络带宽费用、软件服务产品、机房托管费用、域名证书费用。

公有云资源一般包括：云主机、缓存、数据库、流量、存储和弹性IP、SSL（安全套接层协议）证书。

当整理清楚IT资源成本的构成后，随后就可以提出以下几个问题。

1.当前的IT资源有哪些，资源资源利用率有多少？

2.当前的IT资源能否支撑当前业务？

3.在业务不断增长的情况下，IT资源什么时候会达到瓶颈？如果要扩容，该扩容多少？

8.3.3 监控系统和CMDB系统

大中型互联网企业为了能更好地监控应用系统的各项指标和状态，会投入巨大的资源建设相应的监控系统和CMDB系统（配置管理系统）。监控系统不仅能监控业务各项系统状态，还能推动容量管理的优化。CMDB系统则存储大量的软件和硬件资产信息，可以快速地让业务了解当前拥有的资源总数。

1.监控系统

可以通过对各应用元数据的收集、汇总和展示，看到各个业务产品的系统负载，以及应用所依赖的物理资源的使用情况。并且能够通过设置各类元素和指标项的预警阈值，达到有异常就可以报警通知相关人员的目标。

2.CMDB系统

可以管理一个企业的全部服务器，包括物理机和各类云厂商提供的云主机资产，以及相关对应的资源状态、使用人员、产品应用的环境和项目信息，可为其他系统，如监控系统、自动化发布等DevOps类系统提供有效的支撑。

CMDB系统可以进一步提供类似业务线——产品线维度的资源和负载情况，进一步供相关负责人进行分析决策。

8.4 容量优化方式

当我们有了容量评估的各个维度数据后，业务或技术负责人就可以根据当前的容量水位进行扩容或缩容决策，或者根据业务进一步规划后续的容量。容量优化是管理的核心，是容量管理价值的集中体现。我们可以从业务、资源、架构三个维度来进行容量优化。

8.4.1 业务容量优化

业务容量优化需要和业务部门一起评估，如果某个业务处于急速上升期，为了应对业务飞速发展和突发流量，对容量水位的要求会低一些，反之如果某个业务处于下降或产品生命周期末端，对容量水位的阈值要求就会高一些。

8.4.2 资源容量优化

一般来说资源容量优化可以从下列几种维度出发。

1.云主机降配

云主机降配是最直接的，也是大多数开发工程师和运维工程师能第一时间想到的方案。利用云主机动态调整特性，对云主机的一系列参数进行调整，这种优化方式基于单机的监控数据就可以处理。云主机降配比较常见的指标有CPU规格、内存规格、磁盘挂载、使用时长、超售比等。

2.混合部署

站在架构师的角度，业务一般分为在线业务和离线业务。

在线业务。负责和用户交互，以及提供实时数据给用户，对系统的响应时间和可用率都提出了较高要求。

离线业务。负责批量计算，不需要实时响应用户，一般为计算量大、CPU密集型业务，但是对系统的及时性要求低，一般用于批量数据分析计算。

3.混部策略

可以将在线业务和离线业务混合部署，在晚上业务低峰期开启离线业务计算任务，有效地利用CPU，实现峰谷轮动。

一些负载较低或对SLA（系统可用率）要求不高的在线业务也可以进行混合部署，充分地利用IT硬件或云主机资源。

4.网络带宽

在大型互联网企业中，网络带宽的成本是占比较大的一个方面，容易被忽视，成本优化空间很大。

1.外网带宽

大型互联网企业的产品后端架构一般是服务化形式，系统架构师需要系统性地梳理产品及产品线的系统架构，查看服务间的调用是否都是走内网的，如果走外网可以调整为走内网，可以减少外网的带宽成本。

2.CDN（内容分发网络）带宽

业务使用CDN时，主要的带宽成本为CND出口带宽和CDN回源带宽。一般技术层的优化策略可以参考以下几点。

1.增加富媒体文件的压缩比，或使用新格式。

2.配置合理的CDN缓存规则。

3.去问号回源。

4.开启CDN父层。

5.开启CDN分段（分片）回源（缓存）。

6.多个加速域名共享CDN缓存。

7.限制回源带宽。

8.CDN预取（预热）

3. 专线带宽

8.4.3 架构容量优化

1.容灾级别分析和优化

很多产品和服务在上线时，工程师或系统架构师会很自然地采用双服务，甚至多服务集群部署的形态，但是大部分情况下业务对可用性的要求并不高，如后台管理、离线业务，过度的容灾反而会带来资源浪费。

此时需要和业务一起联合梳理并定义整个业务系统的重要级别，保障优先级和可用率，对不同的保障级别和可用率要给出对应的负载和备份策略，以此达到分级区分的目的，这对提升资源的使用率很有效。

2.熔断降级设计

3.过期数据的归档和删除

4.业务系统的性能优化

1.应用层

理论上说如果应用层优化得好，很多的服务器是可以不采购的，但是实际情况下业务根本没有时间和精力去做性能优化。

1.减少数据库的交互。一些上下文所需的数据，如能从缓存里获取就不应该再次请求DB，查询DB比较耗时，频繁地查询数据库不仅会增加数据库的load，还会耗尽应用的连接，影响整个服务的吞吐量。

2.提升热点缓存命中率。如果热点缓存命中率过低，则每次去存储层获取数据效率和响应时间都会较低，可以结合业务看缓存的对象和相关上下文的设计是否合理。

3.异步调用。应用服务会对一些请求做一些附属的事情，但用户并不需要立刻拿到这些处理结果，这些场景比较适合异步优化。异步优化提升了应用的响应时间，提高了并发支持的用户量，还有一个好处就是可以将强依赖转变为弱依赖，提升系统的可用率。

4.线程池优化。批量操作一些异步时需要注意控制线程池的数量，避免突发大批量任务涌进后快速消耗大量服务资源，导致出现线上服务不可用的情况。

5.快速失败策略。系统在调用依赖服务时，如等待时间过长，在突然遭受依赖服务故障，或者依赖服务过载还未熔断时，整个系统的响应时间会被拖长，很容易耗尽系统的线程资源从而导致服务质量急剧下降。做系统优化时，可以系统性地排查应用的依赖点，以及相应的超时时间设置。其他方法有JVM（JAVA虚拟机）调优和减少依赖链路等。

2.数据库层

1.优化SQL。通过优化SQL，可以降低数据库服务器的资源要求。

2.合适的索引。合适的索引可以优化数据库，但不是每个数据都需要被索引，选择需要的数据建立索引，可以规避空间的浪费。

3.读写分离。数据库读写方面的优化有很多，大部分情况下可以做异构设计或队列缓冲设计，降低数据库服务器的规格要求。

4.事务优化。事务优化是非常消耗资源的行为，若使用不当会有逻辑问题。

5.分库分表。分库分表大部分情况下是业务规模等需求导致的额外作用，主要是为了解决数据库的性能问题。

数据库系统优化还需要结合具体的业务综合分析，并做大量的性能压测和业务调优，才能达到满意的效果。

第11章运维基础操作

11.4.2 网络数据包分析

tcpdump以其强大的BPF技术著称，能在链路层抓取各种网络数据包，并对其进行复杂的规则处理。Wireshark则提供了对用户更有好的UI界面，支持各种协议解读等。这两个软件是在跟进网络问题时必备的工具。

tcpdump的功能和作用都非常强，因为是命令行，所以tcpdump在实际操作时还需要很大的学习成本，这对大多数用户来说，在执行各种操作时都非常不直观和不便捷，这时Wireshark就非常有用了。从设计上说，Wireshark既包括tcpdump的功能，又包括很多插件；从功能上说，Wireshark既支持从BT到网络的路由等协议的抓取，又支持定义插件接口，可以方便地处理通信数据。

如，序列为10的包，被Wireshark程序做了深色标记，大部分情况下就是潜在的TCP问题点（标色只是表示异常情况，有时TCP连接还是正常的），在看问题时可以重点关注。