OPS/SRE工程师需要的10种工具

运维、DevOps和SRE工程师都梦想着伟大的工具来管理他们的系统。他们知道，如果这些强大的工具存在并能够处理所有类型的系统、所有类型的体系结构以及系统生命周期的所有阶段，他们的生活将会轻松得多。

什么工程师的梦想：

1）全栈工具–工程师需要全栈工具，从底层到顶层，跨越系统的所有层、服务和部分。

工程师们需要能够真正处理整个堆栈的工具，从物理硬件到公共/私有云和混合云，再到OS、已安装服务、云服务、容器、集群、编排等等。
他们还希望工具能够在设计、提供、构建、编排、监视、管理、调优、疑难解答等方面提供丰富的功能。
当每个人都只看一个孤立的部分时，整个堆栈和糟糕的工程师都受到了影响。

2）读写–工程师需要能够读写系统的工具。

当今的绝大多数工具要么是读的，要么是写的。大多数是只读的，这意味着它们擅长监控，但很少能做任何事情。所有的“操作”都是由ssh、云控制台或其他工具完成的。
只写工具仅限于像Puppet或Ansible这样的编排引擎，或者像Jenkins这样的构建系统，它们的输入只是代码或配置，而不是真正的系统、环境或情况。或者他们可以创建像Terraform或Cloudify这样的系统。
一些监控响应系统（如StackStorm）更好，例如重启服务的能力，但很少能够完成更复杂的更新、配置、体系结构、伸缩或其他重要任务。并且没有人试图将读写系统同步到系统或其环境的统一模型中

3）设计系统–工程师需要一个全堆栈、可视化的设计系统，它可以在任何地方对任何系统进行正向和反向工程。

对于真正的系统，没有实际的设计系统可用。编辑Ansible playbook或更新TerraForm/Cloud Formation与设计系统是不一样的。
一个真正的设计系统有一个全堆栈的可视化设计器和模板，允许重用、验证，并进行正向、反向和更改工程。
它有能力为每个系统的每个部分和每个级别设置所需的一切，包括所有最新的技术，如Docker、集群、云服务和微服务，如Lambda。
一个真正的设计系统可以将一个现有的系统逆向工程到设计器中，允许工程师进行更改，然后将其推回以更新实际的系统。

4）构建、同步和更改–工程师需要能够构建和更新任何复杂性和规模的系统的工具。

世界上缺乏全堆栈构建工具。今天的“自动化”工具是非常由脚本驱动的，与可以被认为是全堆栈的工具相去甚远。虽然他们可以创建一些东西，但他们实际上并不以任何可重复的方式构建整个系统，尤其是在包含诸如Nginx或MySQL这样的服务配置时。
许多当前的工具使用AMI或来自版本控制的基本菜谱/剧本，但缺乏与现有系统同步、处理更改和更新、克隆或差异或真正做更多的从零开始的推动的能力。
新工具需要能够构建、同步和更改。而且，最重要的是，它们需要得到从云和架构到详细的vhost配置选项、mysql选项、Java GC模式等等的全栈支持，当然还有任何和所有云服务、硬件和物理磁盘布局、内核设置、物理网络等等。

5）高级监控和警报–工程师需要对集群和服务进行高级深度监控，这些集群和服务配备警报、通知、自动补救和基于异常检测的预测警报的机器学习。

许多人使用第一代工具（如Nagios、Cacti或mrtg)、第二代工具（如Zabbix）或偶尔使用第三代工具（如SignalFX或DataDog）进行监视。其中大多数具有有限的每服务度量和很少的高级特性，更不用说集群或服务级支持了（尽管它们正在改进）。
很少有人拥有复杂的警报、静音管理、根本原因分析或易于使用的故障排除工具，也没有真正与慢速日志、Java日志或多服务器事件集成。没有自动修复、警报处理或专家系统帮助来排除和修复问题。

6）自动发现和配置-工程师需要能够自动发现正在运行的服务、自动配置它们以进行监视、自动查找服务器和服务之间的各种链接以及自动绘制任何系统的正确图表的工具。

虽然有些工具可以找到正在运行的服务，但没有一个是非常完整的，也没有能力自动配置正在运行的服务以进行监视。
他们不能编写Java JMX配置，不能更改nginx以允许监视，也不能安装所需的模块，更不用说在每个服务器上处理Tomcat、Redis或其他服务的多个实例了。
此外，绝大多数系统无法找到系统之间的链接以及它们如何交互，也无法自动绘制系统架构或操作的图表，尤其是在包含Docker、云服务或集群的情况下（尽管APM正在改进这一点）。剩下的都是那个可怜的工程师。

7）Deep Tech Tools–工程师需要一套广泛而深入的特定于服务的工具，其中包括关键指标、独特的工具和分析、故障排除专业知识和规则系统、动态报告以及特定的操作和自动化。

真正帮助Ops工程师或为专家提供真正支持的工具很少，例如DBA、SREs、DevOps和参与安全工程的个人。当需要对实际系统进行深层问题、调优或故障排除时，很少有工具可以随时提供帮助。
一些不错的系统，如Virtual Cortex，是为特定的服务而存在的，但它们昂贵且仅限于几个单一的服务。很少有工具可以进行实时分析，也没有一个工具真正了解特定服务如何在重载或故障条件下工作和行为。
我们有这些知识，但似乎很少有人能够将其嵌入工程师每天使用的所有工具和系统中。

8）云工具和集成-工程师需要完整的云集成、建模和报告，不仅用于上述设计和构建过程，还用于查找、修复和配置各种云组件和服务。

今天的云工具主要用于成本管理和报告、监控度量以及一些有限的构建集成，如Ansible或Terraform。有一些遵从性系统，比如expendent.io，尽管它们不与其他任何东西集成。很少有工具真正扩展云管理，甚至添加一些基本的工具，比如标记和搜索。
没有真正的专家系统来进行故障排除、性能管理、架构向导、安全报告器、DBA工具等来帮助构建和管理这些复杂的系统。能够完全集成的新云工具应该具有与云组件和系统协同工作的能力，例如搜索和管理标记、管理成本以及提供包括遵从性、审计和安全性在内的报告。

9）运行手册和自动化–工程师需要有效的最佳实践运行手册和过程，包括手动和自动的，跨越整个堆栈和范围的系统、服务和情况。

警报和问题24/7发生，团队需要知道该做什么，如何解决问题，以及让事情恢复在线并按预期执行的关键步骤。但是很少有监控或管理工具有真正的运行手册，更不用说根本原因分析或专家系统来帮助它们了。
此外，几乎没有一个系统能够根据高级警报采取自动行动，尤其是在对管理系统进行适当的安全和保护的情况下。几个系统监控自动伸缩，一对夫妇可以管理它，但自动动作和自动愈合目前不存在。

10）CMDB和审计–工程师需要深度和强大的CMDB来解析、检查和版本化每一个层次上的每一个配置和组件。

配置管理数据库是基于ITIL的IT管理工具的重要组件，但通常仅限于基本硬件规范以及安装的软件和版本列表。他们很少深入研究OS、云或服务（如Apache、Redis、PostgreSQL和其他服务）的实际配置。他们有薄弱的版本和历史记录，通常不知道谁做了什么更改或什么时候做了什么更改。
通常，当前的系统无法比较服务器、发现配置漂移或在发生各种更改时发出警报。此外，它们在动态基础结构、Docker、自动伸缩、微服务和其他现代堆栈元素上的表现也很差。新的CMDB需要集成警报、差异和克隆，并集成到所有其他工具中，以帮助审计、遵从性、监视、根本原因分析和故障排除。
除了CMDB之外，工程师还需要全面的全栈最佳实践审计工具，提供建议，理想情况下，还可以自动纠正各种云、服务、配置和系统中的大多数问题。

通常，今天的审计系统过于简单，仅限于云层或特定服务，如MySQL（即不是全栈）。真实的系统是复杂和动态的，通常很难知道是否遵循了最佳实践和正确的过程，以及系统是否为最佳的可靠性、性能和安全性进行了适当的配置。

结论

如果工程师们有他们的方法，这些管理现代系统的10大梦想工具将成为现实。不幸的是，目前的系统中没有一个真正以它们所需要的方式存在或以最佳水平运行。它们没有以应有的方式完全融合。