“谁构建，谁运行”
--沃纳·威格尔
这样的场景大家想必不会陌生：我们正与家人共度美好时光，突然刺耳的电话铃声嗡嗡响起，我们的注意力也为之吸引。听筒中的尖叫声告知，我们的应用程序——也就是那些定期受到内存泄漏侵扰、但重启之后又能恢复正常的小冤家们——现在终于彻底起义了，服务器资源在几分钟之内就被其彻底榨干。目前该应用已经无法正常起效，而运维团队除了尝试重启与回滚之外无法可想——而最新的一份正常副本已经是几个月之前的版本。没人知道这段时间里系统经历了哪些变更，只有我们自己能够解决这场危机——但现在的我们身在家中，距离办公室和自己的宝贝计算机数英里之遥。
类似这样的状况在传统企业IT模式下可谓相当常见，而开发与运维团队也因此始终站在对立面之上。不过我们完全可以扭转这样尴尬的局面。DevOps不止适用于初创企业，对于成规模的大型组织机构也同样有效。正如自动化机制与客户服务一样，“谁构建、谁运行”的理念完全可以在DevOps模式之下显著改进企业IT的交付效率与效果。
在传统环境下，开发人员、架构师与工程师共同构建起一套解决方案，而后将其交给运维团队打理。有时候前者会提供必要的指导资料来协助后者解决生产环境下可能出现的问题，但有时候前者对生产环境却知之甚少，这意味着他们根本拿不出什么可行的指导性信息。当这些团队彼此之间相互割裂时，各个团队自然不清楚对方的工作方式以及实际需求。运维团队通常依靠运行手册、SOP（即标准化运维规程）或者其它一些固有机制来解决生产流程中出现的问题。这些方案确实能够帮助我们快速解决问题，但却无法从根本上揪出乃至清除问题的来源——这有点像用口香糖修补渗水的船底，最终整条船都逃不过沉没的命运。
DevOps能够带来更好的解决方式
不过云计算的出现不啻为一种福音，它破除了这道看似难以逾越的高墙，让我们能够在很大程度上将基础设施作为软件进行管理。其由API驱动的特性允许大家以对待代码的方式对待基础设施，这意味着开发人员能够顺利解读其中的涵义。现在每个人都能够拉近自身与基础设施间的距离，而良好的运维效果自然也就成了随之而来的关键性诉求。
与此同时，软件的运作方式更趋向于一类服务，客户则要求我们不断对服务做出改进。他们也许能够容忍偶尔出现的错误，但前提是我们有能力立刻修复这些错误并保证其不再发生。为了顺应这一系列转变，我们需要关注细节线索并解读客户并未明确传达给我们的信息。跟我们一样，客户也在忙于处理各类事务，因此当他们打来求助电话时、其内心一定是相当烦闷的。虽然与客户间的交互确实是种增进了解的机遇，但我们还是最好能主动发现问题并防患于未然。不过要得到准确的分析结论，其难度甚至高于传统开发与运维团队之间的顺利沟通——运维人员可能主张快速以治标的方式清除异常，而开发人员则更多考虑到安全性等其它因素、并因此抱持着相对较低的运维效果预期。
所有这一切都成为大家摆脱传统IT模式，转而选择新型DevOps理念的有力理由——在后者的指导下，开发与运维团队将团结在一起并拥有共同的关注方向。对于那些希望在企业当中贯彻DevOps文化的领导者，我一直强烈建议他们遵循“谁构建、谁运行”这一基本原则。下面我就结合亲身经历，聊聊这一原则为企业带来的收益与影响：
· 面向生产环境的设计思路。“谁构建、谁运行”原则会促使开发团队认真考量自己的软件成果是否能够在生产环境下带来与设计目标相符的运行效果。这将帮助技术团队避免最令人头痛的紧张局面，即开发人员想尽办法对已有软件成果进行调整，从而保证其能够在截止日期之前与自己并不熟悉的生产环境相契合。在我自己的从来经历当中，已经无数次见到过这类让人想想就抓狂的状况。大家可以在部署过程中解决生产环境与开发环境之间的一部分差异因素，根据预期运行相关测试，而后观察这些变更会在系统的其它位置引发哪些bug。
· 更理想的员工自治空间。“谁构建、谁运行”理念能够激励每一位员工树立起归属感及责任心，根据我的实际经历，这将帮助企业培养出更多拥有独立能力与责任承担态度的员工，甚至彻底影响企业中的职业发展走向。
· 更高的透明度。没人希望在享受个人时光时受到打扰，而且不用想也知道，被紧急电话惊醒的员工会本能地对相关请求做出拒绝。我们的团队当然希望整套环境拥有更高的透明度并实现积极的监测机制，从而保证问题大规模出现之前就得到识别或者关注。除了抢在异常状况发生前找到问题之外，这种良好的透明度也能够帮助我们更为轻松地定位到问题的根源所在。
· 自动化程度更高。开发人员最痛恨的就是一遍又一遍以手动方式处理重复工作，因此如果他们发现自己被迫在生产环境下不断解决同一个问题时，他们当然希望能够找到问题的根源并一劳永逸地加以处理——而自动化机制正是为这种状况而生。
· 更出色的运维质量。透明度与自动化等因素能够帮助团队获得更理想的执行效率，同时持续提升运维的实际效果。
· 客户满意度更高。“谁构建、谁运行”理念促使整个IT团队积极理解客户的实际需求。这类知识并不再仅仅为产品或者销售团队所重视，而开始更多地成为以反馈为基础的产品持续改进流程中的组成部分。
相信大家在实际应用中还感受到DevOps带来的其它收益，请在评论栏中分享您的切身体会。