在系列文章第一篇和第二篇中，大家已经看到了在CloudBees的帮助下，让管理Jenkins解决方案从一个大麻烦变成轻而易举就能解决的事情。但是，现在让我们反思并退一步。有时候，这些问题并不是表面上的——它们是在成长的过程中造成的，特别是当您的公司现在就需要新功能时；或者是当您收购了一个新的团队，您需要在昨天就为他们安装好！
这并没有留下空间给您在增加工作流程时引入最佳实践，因为最简单的途径可能就是在您的Jenkins实例上堆积更多的东西，或者只是让人们离开并创建自己的实例，这就好比在公司里又建立自己的小公司。这确实是完成了工作，但现在看来呢？并没那么好用了。而且从长远来看，这将给您的软件发布流程带来挑战。在最后一篇文章中，我想提出一些Jenkins实施的基础设施问题——那些隐藏在表面之下的困境。看看有多少人和我有同样的遭遇。不过不用担心，隧道的尽头还是有一线希望的。
不完美的解决方案都有代价
随着您在前两篇文章中读到的困境波及到您的企业，您可能会遇到一系列的下游效应，每一个效应都会对您流水线的工作方式、发布代码的速度以及整个运营成本产生影响。理想情况下，所有这些问题都将受到严格控制，以推进您的业务目标，但正如你我都知道的那样，随着企业规模的扩大，事情很难这样发展。
Jenkins孤岛、Jenkinsteins，还是两者兼有？
不受管理的Jenkins缺点会造成的第一个也是最深刻的一个后果是，它们将不可避免地决定您的Jenkins环境的结构。Jenkins控制器往往会落入三个组织陷阱，每个都倾向优先考虑某些问题，而牺牲其他问题。底线是什么？这些方法代表了一种创可贴式的解决方案（哪里有问题补救哪里），并没有解决它们想要规避的潜在系统缺陷。
Jenkins孤岛：“控制器太多”的问题
由于不受管理的Jenkins会使协作和标准化变得困难，因此团队想要做自己的事情是很正常的。如果允许的话，他们会自行设置控制器，自定义工具链，并在自己认为合适的情况下维护SDLC。这对于少数团队来说已经是很有效的方法了，但对于拥有大量开发人员的企业来说，这只会增加他们的Jenkins困境。这种犹如狂野西部一般的场景产生了Jenkins孤岛现象——无数个互不相关的服务器/团队，经常出现分歧，还会放大沟通、治理、合规性和安全问题。
Jenkinsteins：“巨型单一控制器”的问题
与不受管理的Jenkins相关的大多数困难都来自于试图管理太多的控制器。许多企业都想通过将所有内容放在一个控制器上来解决这个问题。虽然这确实缓解了一些维护、治理和合规性问题，但这带来了新的问题：
- 一台服务器不可能成为团队的一切。有些团队将会放弃首选的定制，甚至是基本的插件(如果它们引入兼容性冲突的话)；
- 在一台服务器上运行所有项目可能会使服务器超载，从而拖慢整个企业的构建和测试时间；
- 单个服务器就会成为故障的唯一来源，而服务器停机可能会破坏整个企业的生产力。
Jenkinsteins+孤岛：“两个世界中最糟糕的”问题
许多企业开始时采用单一控制器的方法，然后最终屈服于给团队自由发挥的需求。单一控制器于离群服务器的组合使得Jenkins环境特别混乱，它结合了这两种场景的缺点，同时还消除了大部分优点。
谁负责技术支持?
在我们探索不受管理的Jenkins带来的挑战时，重要的是要记住，当您遇到麻烦时，社区支持和您自己的团队成员是您寻求帮助的唯一途径。开源社区互助是一个鼓舞人心，但它们并不是企业级的。这可能会带来一些新的问题：
- 以快速增长/转型为目标的企业需要24/7全天候、权威的支持来保持节奏。缺乏专门、可靠的支持服务，将造成支持瓶颈，无形中抑制了企业发展；
- 内部支持会成为一项不受控的开支。随着团队成倍增加，团队成员在自助支持上花费的时间也会成倍增加。这在生产力、预算和增长方面的损失有多大，谁也说不准；
- 停机会使企业陷入瘫痪，造成重大损失。如果灾难发生时没有足够的支持人员待命，这就成为一个真正的风险。
这让我们付出了什么代价？
为什么这些问题都很重要？因为它们最终都会归结为一个价格标签。更糟的是，这个价格标签往往是看不见的。你通常能看到Jenkins是如何帮助你守护底线的，但你不一定能看到它是如何伤害你的底线的。不必要的预算项目可能包括：
- 由于管理开销、故障排除、服务器维护不善、安全漏洞等导致的生产力损失。
- 调度延迟，以为您的工程师每周可能会花费15+小时在管理和支持上，而不是写代码。 工作时间浪费在重复性任务、无望的治理和追求合规性上。
- 错失商机，因为您专注于解决流水线的挑战而不是创新。 工作人员因试图强力解决上述问题而气愤。
- 可扩展性瓶颈——当SDLC很混乱时，您如何根据需要扩展CPU、RAM和磁盘空间？您要么为未使用/闲置的资源付费，要么就在需要时因缺乏资源而阻碍发展。
- 更高的基础架构设施费用——如果您不知道空闲服务器何时处于活动状态，那还怎么从闲置服务器中收回成本？
- 任何来源导致的停机时间——损坏的Jenkinsteins、未识别的错误、兼容冲突、由风险代码引起的网络攻击等。
谁可以在基础设施方面提供帮助？
或者说，隧道尽头的希望在哪里？
又或者说，CloudBees CI帮助你实现最大的投资回报率
下一个问题很明显：你能从哪里得到这一切？最简单的答案是什么？那就是CloudBees软件交付平台。CloudBees CI是该平台的一部分。CloudBees CI缓解了上述所有问题，正如我们在之前的文章中看到的那样。作为Jenkins代码的最大贡献者，CloudBees及其工程师是权威的Jenkins专家。CloudBees团队都很爱Jenkins，但他们很清楚它的潜在陷阱，所以他们致力于最大限度地发挥Jenkins的潜力。
还记得第一篇文章中的这张图吗？它展示了CloudBees CI运营中心（我们之前谈到的集中控制平面）如何重构您的Jenkins环境以促进我们之前谈过的工具包，无论您部署在本地还是在云上。
与一个充满了插件（插件会支持不同的团队，许多许多job会减慢流水线并产生很长的队列）的单个巨型控制器所不同的是，每个团队都有自己的控制器、自己的对象，并在需要时访问共享代理池。
对我来说，这意味着我的团队实现了工作负载隔离——没有其他团队的插件干扰我的插件（我说的就是你们，Java-O团队）。在隔离之外，我们可以通过监视在流水线中可能排队的事件来与其他团队合作（自动化是一件非常美好的事，不是吗？），当我的容量激增时，我们甚至可以跨特定团队共享代理。
我们已经讨论了CloudBees CI可以做些什么来帮助管理Jenkins，你可以了解到客户是如何成功地加快他们的发布周期，但工具集中的另一个工具是CloudBees本身。不是功能，而是人。CloudBees CI是企业版Jenkins——我们了解Jenkins，并为开源社区做出贡献。由于我们为开源项目贡献了大量代码，因此我们有独门绝技，可以在出现问题时解决问题。
使用 CloudBees，您就等于拥有：
- 客户成功经理——客户成功经理通过提示、技巧和更新帮助您优化CloudBees CI体验，确保您始终走在增长的道路上；
- 专业服务——无论您是刚开始使用CloudBees、掌握DevOps，还是从旧模式转向新模式，我们的专业服务团队都能快速帮助您实现目标；
- 卓越的支持
- 最大的Jenkins认证工程师团队为你提供24/7全天候随叫随到的支持；
- 通过与我们的支持团队一起主动规划您的升级，辅助更新可以使CloudBees CI保持最新、稳定和合规；
CloudBees在中国的授权合作伙伴龙智为您提供咨询、实施、培训和技术支持等服务。
今天的Jenkins已不可同日而语——软件交付已经有了进步，开源社区也接受了这项技术，这使得它更容易与最新技术集成，从而推进您的应用程序开发工作流程。它有了更多的集成、更多的作业、更大的灵活性和更强的功能。让CloudBees来引导您实现灵活性，并使您的工作流到达所需的清洁、高效、合规及快速要求。您已经拥有这个力量，让我们来告诉您如何使用它。
作者：萨曼莎·弗罗斯特（Samantha Frost），CloudBees公司产品营销经理。
文章来源：https://www.cloudbees.com/blog/whoa-the-woes-and-fix-your-infrastructure