探索性基础设施项目

如今，大多数公司在其软件开发项目中使用一种或另一种敏捷方法论。 这使得参与软件开发项目的人们至少了解敏捷原则-他们是否真正尝试遵循敏捷实践还是只是出于各种原因向他们口口相传仍然值得商bat。 为了避免与受污染的做法相关联，我宁愿使用“探索性开发”的名称。 与软件开发一样，探索对最终目标目的地有模糊的感觉，并且对如何到达目的地有或多或少的详细了解。 ^{[ 1 ]}在地图上，绘制的路径通常不是直线。

但是，即使DevOps运动的兴起，项目的运营方面似乎仍然没有注意到帷幕另一端的情况。 这篇文章旨在为思考如何将真正的敏捷应用于运维提供思路。

传统方法

例如，我们有一个电子商务应用程序。 有时候，坏的事情发生和开发团队需要访问日志来分析发生了什么事。 通常，由于“安全性”原因，开发人员无法直接访问系统，因此需要要求操作团队发送日志文件。 这种过于常见的过程会导致挫败感，浪费时间，并导致在Dev和Ops之间建造更高的墙。 为了改善这种情况，可以选择设置一个数据存储库以将日志存储到其中，并设置一个Web应用程序以使开发人员可以使用它们。

以下是有关源体系结构组件的一些假设：

• 负载均衡器
• Apache Web服务器
• 部署电子商务应用程序的Apache Tomcat Servlet容器
• Solr服务器，为应用程序提供搜索和构面功能

反过来，需要存储的相关数据/日志包括：

• Web服务器日志
• 应用程序日志正确
• Tomcat技术日志
• JMX数据
• Solr日志

让我们通过弹性堆栈实现这些需求。 目标基础架构可能如下所示：

定义架构通常是不够的。 除非有一家梦想公司的工作能使员工主动改善情况（请寄给我我的简历），否则可能需要对这种体系结构的设置进行一些估算。 如果是为客户公司完成的话，那将会翻倍。 您可能会退缩，说明证据：

工程师可能会认为，经理们要求他们伸出自己的脖子，以提出没有任何实际原因的估计，然后再回头。 但是后者会提醒前者“仅”基于假设进行估算，就好像这是一个真正的解决方案，而不是合理的可否认性。 换句话说，假设是避免错误估计的责任，是的，听起来更接近合同法，而不是工程概念。 这意味着，如果未满足所列的任何假设，则估计错误是可以接受的。 这也意味着估算不再被视为最后期限-如果仅从语义的角度来看，它们永远不会被认为是第一位的。 ^{[ 2 ]}

尽管如此，为了争论起见，让我们尝试回顾与所提议的体系结构有关的可能影响实现时间的假设：

• 硬件位置：内部部署，基于云还是两者兼而有之？
• 底层操作系统：Nix，Windows，其他操作系统或混合操作系统？
• 基础架构虚拟化程度：基础架构是物理的还是虚拟的？
• 操作系统的同一位置：是否有关于物理系统上组件位置的要求？
• 硬件可用性：是否需要购买物理机？
• 自动化准备情况：是否已存在用于自动化基础架构管理的解决方案？ 如果不是，则需要在几个环境中设置实现；如果超过2个，将手动处理复制吗？
• 群集：是否有任何组件群集？ 哪个）？ 对于该应用程序，是否有会话复制解决方案？ 哪一个？
• 基础架构访问：需要在现场吗？ 需要获得安全令牌硬件吗？ 从软件？

这些只是关于硬件的非常基本的项目。 其他广泛领域包括软件（日志量，严重性，硬件/软件不匹配/不匹配，版本等），人员（内部支持等），计划（休假季节等），我大概是也忘记了一些重要的东西。 鉴于可用项目的绝对数量-并假设所有项目都已列出，因此有理由推论至少一个假设将被证明是错误的，因此使最终估计完全错误。 在这种情况下，玩估算游戏只是提供合理可信度的另一种方法。 一个更有用的替代方法是创建所有项目的n维矩阵，并估算所有可能的组合。 但是，就像在软件项目中一样，事件空间具有太多参数，无法在可接受的时间范围内执行此操作。

替代方案

也就是说，一个真正可行的替代方案可能不是满足仪表板经理的要求，而是满足底层业务的要求？ 首先要实现最基本的要求，然后添加更多功能，直到功能足够好或花费了足够的预算为止。 以下是上述示例中的一些可能步骤：

基础设置

该设置的最初目标是启用日志访问，最重要的日志是应用程序日志。 因此，第一个设置如下：

更多JVM日志

从现在开始，几乎零的工作就是添加抓取Tomcat的日志，以通过添加相关性来帮助进行事件分析。

机器解耦

下一步的逻辑步骤是将Elasticsearch实例移至其自己的专用计算机上，以向整个体系结构添加额外级别的模块化。

甚至更多的日志

此时，可以将来自其他组件（负载平衡器，Solr服务器等）的其他日志发送到Elasticsearch，以改善涉及不同组件的问题解决方案。

性能改进

鉴于Logstash用Ruby编写，直接在组件上运行Logstash可能会遇到一些性能问题，具体取决于每台计算机的特定负载和性能。 Elastic在一段时间前就意识到了这一点，现在通过专用Beat提出了更好的性能。 每个Logstash实例都可以用Filebeats代替。

不仅是日志

使用Jolokia库，可以通过HTTP接口公开JMX bean。 不幸的是，只有少数可用的Beats，它们都不处理HTTP。 但是，带有http-poller插件的Logstash可以完成工作。

可靠性

为了提高可靠性，可以对Elasticsearch进行集群化。

这些步骤的好处是，它们可以按（几乎）任何顺序执行。 这意味着，在奠定了基础基础之后（第一步），利益相关者可以决定哪一个对它的特定上下文有意义，或者停止，因为对于增加值就足够了。

在这一点上，估计对于第一步仍然有意义。 但是，在消除了大多数复杂性（及其相关的不确定性）之后，在特定情况下估计弹性堆栈的设置要舒适得多。

结论

如上所述，是否在软件开发项目中实施敏捷原则尚有争议。 但是，我的感觉是他们还没有进入Ops领域。 真可惜，因为在开发中，项目可以真正从真正的敏捷实践中受益。 但是，为了防止与敏捷货运邪教组织联系，我建议使用“探索性基础设施”一词。 这篇文章描述了将这种探索性方法应用于示例基础设施项目的提案。 这种方法的主要缺点是，它的成本更高，因为路径直。 主要的好处是，在考虑到收益递减规律的情况下，利益相关者可以在每一步中选择追求还是停止。

---

1 。 笑话，这是HTML笑话，因为“强调少”

2 。 如果确实需要将估计值作为估计值，则可以使用复合词猜测值。 企业语义不是很棒吗？

翻译自: https://blog.frankel.ch/exploratory-infrastructure-projects/