企业DevOps：实施过程中需要关注的各项要点_devops tools技术关键点包括

作者：亚马逊云科技企业市场战略总监 Stephen Orban 

 

 

“经验并非凭空创造，而是依靠点滴积累所实现”

---阿尔贝·加缪

 

在此次的企业DevOps探索之旅系列文章当中，我将带大家一同探讨企业在具备一定DevOps经验之后又该如何处理下一步可能面临的状况。当然，这些只是我个人在接触自动化、面向客户服务之IT体系以及“谁构建、谁运行”方面事务的同时积累下的一些心得体会。

 

不要对DevOps实践的发展进程抱有过高期望

与其它有价值物事物一样，DevOps文化的实现推行也需要投入大量时间。我建议大家遵循从小处入手且循序渐进的执行方式，同时认真衡量每项组织变更给企业带来的实际影响——接纳实际起效的作法、并从未能奏效的举措当中总结经验教训。如此一来，相信持续改进这一文化体系必将在企业当中生根发芽。而且在整个实施过程中，最困难的无疑当数起步阶段。当大家已经逐渐适应了DevOps文化所带来的各种变化之后，接下来企业可能会面临着一系列独一无二的实际挑战——不过请大家坚定信心，这些困难出现的同时也意味着我们距离理想的解决方案已经不远了。

当初我们在道琼斯公司推广DevOps理念时，起步阶段仅仅组织起一个四人团队，并采取了一种相当缓慢的规模拓展方式——每月从其它IT领域借调一到两位成员加入队伍当中。如此一来，我们得以构建起一整套经验与最佳实践体系，而且始终保证当前项目数量能够与我们应用DevOps的节奏相统一。我并不建议大家在这个阶段采取过于迅猛的推进态度。缓慢而经过深思熟虑的增长能够帮助我们设定出与相关人员（也包括我们自己的这支队伍）的期望更为契合的发展目标，而一旦速度太快，情况很容易超出控制。另外，这种方式还能够保证资源消耗水平与整体业务收益保持平衡，这样我们就不必担心在资源分配方面受到过多的政策性干预。

整个发展过程大约用去了十八个月时间，这时我们感觉自己已经构建起一套足够庞大的最佳实践、自动化机制以及治理模式储备，可以开始将更大比例的基础设施资源划拨给DevOps团队了。在这方面变更当中，我们的目标在于让各位成员利用DevOps团队随时间积累下的经验对自身的传统角色定位进行转换。人们不可能在一夜之间彻底颠覆自己的固有工作方式，因此我们需要将这种转变划分成一个个组成部分，并由成员们自行调整相关系统的管理习惯。

 

在DevOps的实施范围及实施方法方面采取开放态度

毫无疑问，并不存在一种能够应对各类实际状况的DevOps实现与经验积累办法。每一家企业都拥有自身独特的情况与需求，而且并不是每家企业都需要——或者说应该——针对DevOps作出调整与变更。大家应当做好对相关举措的实际效果进行量化的心理准备，同时寻求一种将DevOps理念以及/或者相关团队同业务收益相结合的可行途径——这种业务收益可能体现在IT的任何一个方面。目前业界通常强调的是DevOps理念的实现方式以及创新文化在产品开发中的具体应用，不过我个人亲眼见证过很多成功的案例，证明DevOps也完全可以在后端办公、最终用户计算乃至IT的其它侧面发挥重要作用。总而言之，请大家以开放的心态看待当前正在推进的各类项目，这将帮助各位始终专注于DevOps团队的培养工作，并了解其该以何种方式带来令人满意的成果。

 

下面我们来了解企业在实现成熟DevOps文化之后所体会到的实际收益：

动中取静——保障一致性。DevOps文化的实际表现应当被视为频度更高且规模更小的一系列变更的集合体。我曾经在此前的文章当中探讨过这一点，并列举了由此带来的各类收益，包括带来更理想的执行效率、分配给业务需求的资源更为丰富以及更出色的运营效果等等。这一切最终都将给客户带来更令人满意的使用体验（无论是内部客户还是外部客户）。但与此同时，大家需要准备好对业务相关者们的预期进行管理，而且不要任由他们抱有错误的预期。这绝不是危言耸听，事实上很多相关人员都会将持续变更的产品或者环境视为一种潜在风险。我们需要投入时间并拿出理想的成熟度来建立并证明DevOps是一套负责任的执行理念。最根本的一点就是建立信任，而建立信任绝不可能一蹴而就。总而言之，如果达成了预期目标、同时却失去了客户的支持，那么我们相当于不战而败。

全球性分布式应用。作为一名IT从业者，最令我感到振奋、或者说让我感到自己的工作有所回报的时刻，就是看着一款应用程序在世界各时区范畴之内不断进行着规模伸缩。由于大家的DevOps团队已经了解到如何以自动化方式管理跨越不同区域的整套资源储备，因此将应用程序推向分布式与全球化就成了顺理成章的下一步工作。让服务交付设施与客户距离更近能够有效降低延迟、使系统执行效率更高、更具成本效益，当然同时也能提高客户的满意程度。当大家掌握了DevOps的奥秘，将应用程序以分布式机制拓展到全球范围并不是什么难事。

数据中心迁移。IT部门的一切工作都应受到业务需求的直接驱动。而当IT管理者能够将某种传统IT举措提取出来并作为真正的商业实例加以运营时，他或者她就不再仅仅是一位IT负责人、而开始转型成为商务领导者了。利用现有自动化与全球化分布式应用程序储备，大家能够开发出令人瞩目的商业安全，并将一部分或者整体数据中心迁移至云环境当中。在过去的一年中，我亲眼见证了越来越多此类案例的出现。

我个人的基础设施迁移工作出现在道琼斯公司运行自有DevOps团队的大约十个月之后。当时我们在香港租用的数据中心再有几个月就要到期了，这意味着我们必须尽快找到新的基础设施托管平台。我意识到我们已经拥有强大的DevOps实践与云专业知识储备，因此继续畏首畏尾地将自身局限在数据中心之内不单是一种退缩、更是一种耻辱。

在克服了一系列阻力之后，DevOps团队掌握了困扰工程师们的各类主观障碍，并在六周之内将数据中心负载整体迁移到了亚马逊云当中。尽管那时候的具体部署方式与当下的主流机制大相径庭，但最终我们还是顺利完成了迁移工作，而且直到现在我也认为这是对专业知识储备与期望管理效果的一种最具实效的证明手段。如果没有过去积累到的一系列经验，我们根本不可能完成这项迁移壮举。

大家在实际工作当中又有着哪些值得分享的心得与体会？请在评论栏中留下您的真知灼见。