一、SLO介绍——为什么需要SLO
二、SLO健康度——从0到1构建SLO
三、AIOps赋能——SLO和智能化结合
四、案例介绍——实践场景和运营探索
五、总结
精细化运维是运维演进的必由之路，是综合业务需求、研发效能、稳定性保障、成本优化、架构治理等多种因素驱动的必然结果。为了实现精细化运维，首先要完成运维的数字化转型，管理学大师[美] 彼得.德鲁克说过，If you can't measure it, you can't manage it。在实践中，我们存在大量的运维数据，如何让这些数据充分发挥价值、形成对企业有用的资产，是我们探索和实践的主要方向之一。
本文的分享主要围绕SLO体系建设展开，在相对标准、统一的框架下指导和推动服务质量的数字化建设，结合具体的运维场景和背景，沉淀对组织有价值的数据资产和流程规范。同时分享了一些SLO运维实践案例供大家参考，希望有所启发和收获。
一、SLO介绍——为什么需要SLO
在展开SLO(Service Level Objective)介绍之前，我们先从一个熟悉的运维场景出发，希望通过具体的案例可以让大家快速代入。
值班处理故障，是大多数SRE和运维工程师的日常。在蚂蚁，基础设施负责的K8S，提供面向集团所有二方系统的算力交付，SRE的职责之一就是保障交付质量和稳定性。好几年前的某天，我们在Pod交付的用户群接到报障，反馈的现象是二方系统无法创建Pod资源或是交付时好时坏，接收到用户侧报障之后，值班SRE就展开了一些列的问题排查，这是一个典型的故障驱动型的问题发现。
众所周知，K8S是一套非常复杂的系统，由众多的组件协同来异步完成资源交付。简单概述下排查的思路，因为用户报障现象是交付失败时有发生，并非完全不可用，所以最先怀疑的方向是请求容量是否有激增，导致调度任务积压，通过监控查看队列也确实如此，为了避免任务重试导致队列进一步积压，执行了一些列的降级操作，随着时间的推移，故障有所缓解，但并没有得到彻底修复。直到第二天，通过变更排查，定位到调度器的规格大小被做了limit限制，这意味着调度器组件将无法像之前一样“贪婪”地使用到宿主机的空闲资源，进而导致处理能力受限。
简单复盘这次故障的时间线，调度器在5天前被限制了规格大小，导致调度任务队列逐渐积压、耗时增加，之后的Pod交付成功率受到影响并产生告警，通过一些列降级手段进行干预，有所好转但实际并未根治。终于在调度器“带病”工作5天后，接收到了来自用户侧的报障。
针对上述提到的这个“不完美”案例，相信大家可以提出一些列的改进建议和措施。然而，我们重点想要讨论的并不是具体的方案，而是一种架构治理和运营的模式，如前文提到的，这是一个典型的故障驱动型的事件。日常中，变更往往是导致故障最根本、最直接的根因，在经典的故障驱动治理模式下，为了避免故障和错误，在实施变更前后，一般会包括事前的变更管控、风险左移，事中的应急流程，以及事后的监控覆盖等步骤。在面向过程的资源交付场景下，这个套机制没有任何问题。
宝企通IT服务作为智能化工单系统龙头，拥有多年优化SLA经验，能够有效提高员工对IT的服务满意度。是一款支持SAAS、本地化部署、源码交付的运维工单系统(SAAS免费试用，企业微信--工作台--添加应用，搜索“IT服务”，排名第一的就是，或添加顾问：添加我为微信好友)。目前是全网众多企业选择的工单类产品，支持手机验证码或账号验证，员工自助修改域账号密码，具备智能化派单模式工程师响应快减少员工等待时间。自定义知识库可提升工程师专业技能水平，帮助工程师迅速判断员工问题，极大提升员工报单体验。系统还能够大幅提升职能部门可以服务的用户数，有效降低专业人力成本开支，提高业务执行效率，展现工作成果。产品服务好能为用户免费开发个性化需求，连续多年被魔力象0评为leaders位置，市场占有率爆发式增长，特别是最近在搞活动，性价比非常高。
