一、系统可靠性

SRE是判断系统是否可靠、可用、有效重要标准，它包括：

• 服务水平指标SLI：衡量服务使用情况量化指标。 比如IO读写速率、网络延迟。通常量化指标会转换为比率、平均值或百分比。
• 服务水平目标SLO：一段时间、区间内的目标。 SLO的表达式通常为： SLI <= target 或 lower bound ≤ SLI ≤ upper bound。比如SLO可以为每个请求的平均延迟<=10ms。
• 服务水平协议SLA：测量指标应与商业目标密切相关。

稳定性99.99% 和 99.999% 在大部分情况下对用户体验差异不大，但每增加一个9，会显著增加成本。

基于时间的可用性=可用时间/总时间，但该指标通常意义不大。比如某订单系统在7天内有1小时不可用，其影响将是致命的。

基于成功率的可靠性=成功请求数/总请求数。选择何种可靠性级别主要依赖于用户风险承受能力，在创新和可靠性之间找到恰当的平衡。

度量建模首先需要对指标进行标准化，比如聚合间隔、聚合区域、测量频率、包括哪些请求、如何获取数据以及数据访问延迟。进行度量选择时，应关注用户关心的内容，而不是能够衡量的内容。关注标准化指标时，需关注SLI分布而不是平均值。

以上图为例，紫色区域整体较为稳定，状态较好；而蓝色区域毛刺突出，意味着系统在某一个时间点资源占用出现问题。

在事件处理中，需要在事件发生前做异常演练、趋势分析、告警等，在事件发生后及时呼叫相关工程师做根因分析，现场补救，进行错误修复。然后将补救经验沉淀到知识库，后续用于自动化修复。

不同业务会有不一样的监控指标，不同的商业目标也会有不同的SLO。

上图展示了操作系统的可观测维度。

这里我们列了一个矩阵，Y轴是可靠性通用度量方法，X轴是系统的可观维度，通过X和Y轴的组合，可以生成操作系统的SLI度量项。

对于SRE而言，监控也十分重要。监控可以分析长期趋势，比如查看每日活动用户数据量、增加或减少、数据库使用了多大的磁盘、何时需要做扩容；也可以用来比较不同时间或实验组，比如不同组件查询速度比较、内存命中率比较、网站运行速度比较等。

监控可以大幅提升运维效率，不再需要运维人员、用户手动登录检查系统状态。另外，它也可以用于临时性的回顾分析，查看某个时间点具体发生了什么、哪些指标出现了异常。

监控的基本原则是症状与原因，监控系统应该解决两个问题：什么坏了？为什么？

监控具有四个黄金信号，分别为延迟、流量、错误，饱和度。监控的工作内容应尽量简单，最常捕获真实事件的规则应尽可能简单、可预测和可靠，很少使用的数据收集、聚合和警报配置应被移除，已收集但未在任何仪表板中公开或被任何警报使用的信号应删除，方能达到高效分析问题的目的。

系统自动化能够解决一致性、一个平台、更快的维修与行动以及计划的问题，后续，我们也期待能够通过AI OPS实现智能识别、智能介入以及智能修复。

sysOM致力于打造一个集主机管理、配置部署、监控报警、异常诊断、安全审计等一系列功能的自动化运维平台。目前我们对资源管理做了纳管、监控，对配置管理做了安全、包管理、自动化，对权限管理做了权限细分、审计拦截，也实现了主动诊断。

上图为SYSOM的主机管理图，可以做主机的批量导入、导出、删除，也可以根据集群做分门别类的梳理，支持在线终端，为运维人员带来了极大的方便，无需额外安装专门的客户端软件，只需一台电脑，登录SYSOM服务即可直接访问外部终端，达到运维目的。

上图为SYSOM 诊断中心，负责检查调度、内存、IO网络、补丁 CPU 等，并针对问题进行告警。

上图为网络诊断图。

二、系统安全性

系统安全性包括静态应用程序安全检查、动态应用程序安全检查以及软件生命周期保护。静态应用程序安全检查一般为在开发阶段做源码扫描勘测，判断哪些编码可能会出现漏洞；动态应用程序一般对正在运行的二进制开启端口渗透，查看是否存在漏洞。

软件生命周期维护分为三个部分：

• 基线：包含软件版本和配置文件。告知用户安全的软件版本和配置文件，即使出现高危漏洞也不会产生太大影响。
• 漏洞库：存储软件出现的漏洞以及出现漏洞的版本。
• 修复：对软件包进行升级或补丁。

上图为SYSOM 安全中心，能够直观地为用户展示需要修复的漏洞数量、高危漏洞数量、修复漏洞影响的主机数量、今天修复的数量、累计修复的数量等。安全中心既能支持多个漏洞批量修复，也支持多个主机漏洞批量修复，可以一次性将所有主机的所有漏洞进行修复。

不同漏洞数据库包含的漏洞数据可能有缺失，SYSOM安全中心支持第三方数据库接入，只需配置名称、连接地址、请求方式等，即可将第三方漏洞数库数据导入到 SYSOM 安全中心，进行系统扫描。

上图为安全扫描结果展示。

三、展望与挑战

当前，系统稳定性存在若干痛点。

首先，事件现场的保留。故障事件发生之后，现场难以保留，分析时需要花费较大代价。因此，保留事件现场尤为重要。

其次，底躁问题。监控时，监控指标会对系统带来一些负载，做巡检和指标计算也会对系统带来负载，我们期望以尽可能低的底噪来达到更全面的监控，也是将来需要解决的问题。

最后，修复依据。做安全基线配置或问题修复时，大多依靠专家经验和厂商经验。但是每个厂商或每个专家各有自己的观点，我们需要将其形成一套标准化规范。

原文链接

本文为阿里云原创内容，未经允许不得转载。