4款SRE利器

站点可靠性工程师可能只是被他们组织的其他部分视为现代巫师。他们预计将与现代云原生应用程序一起工作，这些应用程序比以往任何时候都更加复杂，并利用DevOps和站点可靠性工程技能。此外，这些工程师在使用这些复杂的应用程序时必须扮演几个角色，使用强大的工具，自动化可重复的过程，并尽可能减少辛劳（即手动步骤）。总而言之，现场可靠性工程可能是一项艰巨的任务，需要正确的SRE工具。

站点可靠性工程师的角色到底是什么？

这个问题的答案可能会有所不同，这取决于你问的是谁。谷歌简洁地将其描述为“当你将操作视为软件问题时，你会得到什么。”随着云应用程序在“堆栈”中越走越高，将操作视为“软件问题”变得非常必要。与传统应用程序不同，现代云原生应用程序依赖于底层基础设施、容器、运行时、云服务、编排和软件交付生命周期自动化的复杂层。这个“云栈”变得过于复杂，无法手工管理，必须实现自动化。因此，需要将许多操作视为软件问题。
但通常，云原生应用程序的复杂性意味着SRE不能遵循其工作应该是什么样子的单一“教科书定义”。相反，他们完成一系列活动，这些活动取决于他们的组织是如何设置的。
根据Catchpoint的《2021 SRE报告》，大多数SRE花了大量时间

• 响应事故或中断
• 执行尸检分析和/或记录
• 参加随叫随到的轮换
• 开发应用程序或功能
• 为扩展知识或技能而进行实验或接受训练的
• 编写业务流程、规则或最佳实践
• 对使用/成本分配进行审计
• 创建新的主机/实例。

SRE工具类型

为了执行所有这些任务，特别是在注重提高自动化和避免劳累的同时，SREs需要良好的工具。以下是任何SRE都应该拥有的4个至关重要的工具。

基础设施即代码工具

基础设施即代码（Infrastructure-as-code,IaC）工具允许SRE以编程方式提供基础设施。使用IaC工具，SREs定义了计算、网络和存储服务的配置、大小和配置方式。对于大多数组织来说，这种能力是自动化软件交付生命周期的基本先决条件，正如我们前面所看到的，自动化软件交付生命周期是能够持续部署的先决条件。
例如：Terraform,AWS CloudFormation,Ansible,Puppet。

可观测性工具

接下来，SREs需要可观察性工具来快速、最终地诊断问题，而不必预先设置特定的监视器。与监视不同，监视旨在回答您配置它所针对的特定问题，可观测性捕获足够详细的数据，因此您也可以回答您事先没有想到的问题。
可观察性工具提供对应用程序生产性能的洞察力，并从用户的角度显示它们的运行情况。这些工具还收集战略分析，将应用程序的持续性能与SLA和其他操作指南相一致。
可观测性的支柱是

• 关于软件行为的大量（“高基数”）丰富（“高维度”）数据点
• 记录软件组件执行时发出的消息
• 请求跟踪，用于跟踪跨服务集的事务执行。

例如:Dynatrace、AppDynamics、DataDog、New Relic、Honeycomb。

事故管理工具

云原生应用程序变得越来越复杂，并且可以随着时间的推移而快速发展。这使得确保代码和配置始终正确，并且始终有足够的可用资源变得具有挑战性。此外，云原生应用程序可能有大量的直接和间接依赖关系，从而使操作方程进一步复杂化。结果，事件不可避免。
但事故也是高压力事件，至关重要的是，事故的反应是尽可能合作和无摩擦地进行。事故管理工具为SRE提供了工作流自动化，它们需要将注意力集中在事故上，对警报进行分类，任命事故指挥官，并在不遗漏步骤、重复工作或循环的情况下运行最快的解决过程。
例如：巡逻，中队，随叫随到。

运行时工具

最后，SREs还需要一种方法来快速查看正在发生的事情，并在出现问题时对其做出响应。这意味着他们需要能够
请参阅“森林，而不是树木”，这样他们就可以快速识别运行时压力和不良行为的来源
在运行时控制生产行为，而不必调整配置或依赖开发来处理补丁。
如果没有方法来完成这两件事，工程师就无法将运行时行为上下文化，只能应用粗糙的、不精确的度量，如回滚部署或重新启动实例。

总结

尽管基础设施即代码、可观察性和事件管理工具本身非常有价值，但它们迫使SRE花费数小时进行诊断，然后设计和发布补丁。
通过运行时控制，工程师能够看到森林，而不是树木，立即识别运行时压力来自哪里，并知道当问题出现时需要主动地、提前地或反应地做什么–手动或自动地。
因此，可靠性得到最大化，安全性得到加强，性能和成本得到优化，客户体验得到保证。