运维大乱炖：被99.99%的SLA搞破防了！

乱炖的起点

小伙伴分享的：“搭建和维护CI/CD流水线，保障业务系统高可用性(99.99% SLA)。”

关于SLA指标99.99%，在运维小伙伴们之间炸开了锅！

这个基本上是理想值，可以达到但是靠运气!
4个9其实本身的逻辑是不成立的，先决条件很重要，这个不对齐，很多逻辑就验证不了，不科学！
监控是提前预警，让发生故障的频率降低。这不是一个人的事情。
监控能预知90%的风险，但还有10%的，只能用整个运维机制、架构完整性来保障了。
需要建设的运维指标也会很多，比如：可用性、故障率、平均修复时间、平均故障间隔时间、响应时间、吞吐量、错误率、延迟、数据完整性、系统响应成功率、平均等待时间、数据备份成功率、数据恢复时间、服务器利用率、网络带宽利用率、版本迭代成功率等等。需要长时间的磨合，才可能无限趋近。
如果预算是无穷大，我感觉这事也简单，设备买大厂高端，高可用+冷热备，再上个我们的智能体，所有智能体提供的建议都严格执行。
一般4个9，各种冗余+一些运气，整体还是能长期做到的。但是5个9挑战就太大了。
这个和智能体是否参与关系不大，外部不稳定因素太多了。基础设施、应用系统、中间件的SLA级别就是不一样的，一刀切的话不合理！
分析和决策能把这些技术在一个平台对齐就很不错了，这个都不能在一个平台监控，和关系解构，谈变更为时尚早！
我们聊SLA，或者说SLO、SLI这些协议和指标，要严谨和科学一些，不断去和业务团队沟通，让他们能认知到这个协议的真实意义以及可行性。正常来说业务方认为服务应该就是100%。
经各抒己见后，可以看出大家都有自己的运维之道，只是视角不同，都在为这个未至之境贡献自己的力量！

SLA(Service Level Agreement，服务级别协议)中的“9”用来量化服务的可用性水平，通常以一年内服务的正常运行时间占总时间的比例来表示.每个额外的“9”代表着更高的可用性和更短的预期停机时间。
99.99%(四个九)：对应一年中服务的最大中断时间为0.876小时（约52.6分钟），即在近一年时间内有不到1小时的中断。
一体化监控

“分析和决策能把这些技术在一个平台对齐就很不错了，这个都不能在一个平台监控，和关系解构，谈变更为时尚早！”

在上述SLA讨论中其实已经被这句话吸引住了，因为单就监控平台来说，运维面临的监控工具种类多、管理分散，在维护大量不同工具同时还需持续更新监控策略，维护成本高。

既然运维老司机们给了我们一个一体化监控的思路，那我们就来了解下体系相对比较完善的金融行业关于一体化监控建设的一些实践经验！

一体化监控建设核心需求

监控策略自动上收管理周期性上收不同工具的监控策略并统一管理，依据IP地址和主机标识明确监控对象，对齐同一对象在不同工具中的策略粒度，形成标准化管理对象，实现全局监控覆盖实时监测，减少监控盲区。
可视化配置信息表建设构建“监控对象—监控策略”配置信息可视化展示表，由监控管理人员补充策略功能描述，方便应用和系统管理员直观查询负责系统的监控覆盖情况，高效差缺补漏。
监控事件统一管理上收不同监控系统的告警事件并统一管理，降低值机人员工作量，规范通知通报信息来源与流程，为后续智能化告警分析、自动化处置流程建设铺垫。
行业参考建议

梳理监控系统并分类明确需接入一体化监控平台的系统，按功能、北向接口、监控对象分类；不同功能系统可采用策略累加、事件集成，同类功能或策略重叠系统需设计重叠策略的标准化格式并归并。
设计映射表梳理各系统监控策略与对象并分类，设计适配自身的“监控对象—监控策略”映射表（包含IP地址、主机标识、策略名称、阈值、轮询时间、告警级别等信息），支撑后续数据采集与存储开发。
按需建设一体化平台监控工具多、管理分散时，可搭建一体化监控平台整合策略配置与事件管理（底层工具上的整合管理平台）；系统规模小、监控系统单一则无需额外搭建。
3条技术路线

通过以上实践需求和参考建议，一体化监控建设也是需要我们下大功夫去建设的，但这让我想起了之前【twt企业IT社区】分享的一体化监控项目建设3条技术路线，我们可以作为参考！

商业成品（COTS）方案，初始许可费用高，长期维护成本可预测，风险在于供应商锁定、存在监控盲区、扩展成本阶梯式跳增；
开源框架+自建监控路线，初期工具成本低，隐性成本高，需持续投入人力和社区生态，风险在于分析层能力碎片化，无法开箱即用；
混合技术路线，初始工作量集中于自建开发，成本取决于商业组件长期占比，风险在于技术组合可能导致“伪标准化”，但降低了供应商锁定风险；
乱炖总结

运维永远追求的都是诗和远方，而当下运维眼前虽然可能是一片沼泽地，稍有不慎会深陷泥潭，但“平静的大海培养不出优秀的水手”，我们总要在外部因素+技术手段+运维保障机制+业务协同中找到一个支点，向99.99%的SLA去进发！