当我是一名运维顾问时，我有幸在相对较短的时间内看到了许多公司阴暗的一面。这种幸运在一个客户项目中尤为突出，我成为了一个内部部署工具的维护者，这个工具已经膨胀到几乎触及到每一部分基础设施——尽管缺乏文档和测试。对于维护这个庞然大物同时还要处理改进产品的实际工作这项不可能完成的任务感到沮丧，我开始回顾我以前的客户项目，并向我的运维社区探寻他们的策略。我发现“非我发明” (NIH) 综合症以及与更广泛的社区缺乏合作的情况十分普遍。
NIH 的问题
NIH 最大的问题之一是工程师的时间消耗。他们没有致力于为业务增加价值的功能，而是在为解决部署、持续集成 (CI) 和配置管理等标准问题的工具添加功能。
对于中小型初创公司来说，这是一个严重的问题，在这些公司中，新员工需要立即上手。如果他们必须学习一套全新的工具，而不是利用他们使用行业标准工具的经验，那么他们变得有用的时间就会大大增加。当新员工正在学习内部工具时，公司仍然依赖于少数编写这些工具的人员来记录、培训和排除故障。天哪，如果其中一位工程师屈服于巴士系数，因为如果他们忘记记录某些内容，获得外部帮助的可能性为零。
你需要自己开发吗？
在编写你自己的运维工具之前，先问自己以下问题
- 我们是否已经向更广泛的运维社区征求过解决方案？
- 我们是否已将专有工具的成本与维护内部解决方案所需的估计工程时间进行了比较？
- 我们是否已经确定了开源解决方案，即使是那些缺乏所需功能的解决方案，并尝试为它们做出贡献？
- 我们可以 Fork 任何编写良好但未维护的开源工具吗？
如果你仍然找不到满足你需求的工具，你将不得不自己开发。
自己开发的技巧
这是自己开发解决方案的清单
- 内部工具不应免除您应用于其余代码的高标准。像要开源它一样编写它。
- 确保您在 Sprint 中留出时间来处理功能请求，并且不允许在进行适当的测试和文档记录之前匆忙添加功能。
- 保持小巧。如果你的工具是一个触及一切的庞然大物，那么要制定任何形式的退出策略将更加困难。
- 跟踪你的工具的使用情况并删除未积极使用的功能。
制定退出策略
开源你的内部工具本身并不是退出策略，但它可以帮助你获得外部贡献者来解放你的工程师的时间。这是一个更困难的策略，需要额外的注意和计划。在致力于这条道路之前，请阅读“启动一个开源项目”和“你已决定在工作中开源一个项目。现在怎么办？”。如果你对更干净的退出感兴趣，请每季度留出时间来研究和测试新的开源替代品。
无论你选择哪条道路，明确声明内部解决方案不是首选状态——在其开发的早期阶段——应该消除任何困惑，并防止改变方向的问题变得政治化。
Sabice Arkenvirr 将在 LISA18（2018 年 10 月 29 日至 31 日，美国田纳西州纳什维尔）上展示 我们已经有了好东西，使用它们！。
评论已关闭。