一、系统可靠性
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 安全中心,进行系统扫描。
上图为安全扫描结果展示。
三、展望与挑战
当前,系统稳定性存在若干痛点。
首先,事件现场的保留。故障事件发生之后,现场难以保留,分析时需要花费较大代价。因此,保留事件现场尤为重要。
其次,底躁问题。监控时,监控指标会对系统带来一些负载,做巡检和指标计算也会对系统带来负载,我们期望以尽可能低的底噪来达到更全面的监控,也是将来需要解决的问题。
最后,修复依据。做安全基线配置或问题修复时,大多依靠专家经验和厂商经验。但是每个厂商或每个专家各有自己的观点,我们需要将其形成一套标准化规范。
本文为阿里云原创内容,未经允许不得转载。