我们的DevOps如何让客户生产环境从“0”到完全恢复
By 老彦
人能弘道，非道弘人
– 论语.卫灵公
危与机的开始
最近工作有些吃力，11月4日当天特意请了两小时假，提前下班，吃完晚饭刚坐下来，打算简单看个电影，然后好好睡一觉恢复下体力。不想发生了一次突发事件。
19:43，有同事在群里问是否能连上客户的服务器，一开始也没有太当一回事，服务器连不上也许只是网络暂时情况。
20:26，刘博在群里紧急拉DevOps的同事入群，心里咯噔一下，看来是出了点状况，赶紧坐到电脑前开始关注群里的沟通。
20:36，一阵急促的电话声，刘博来电，果然事情有点不太妙，新资产的应用服务器重启后就无法启动，应该是宕机了，DevOps团队需要全员上线应急恢复服务器应用环境，崔总开始协调第三方系统集成供应商恢复服务器的基础操作系统，幸运的是目前只有新资产系统的应用服务器宕机，数据服务器安然无恙，刘博指示先备份数据服务器上的所有相关数据，以防万一。
20:50，我们开始等待第三方供应商完成服务器操作系统的重新安装，同时内部分配每个人的VPN账号，进行数据库和文件存储的备份。
21:36，参考之前准备的资产系统部署手册，团队基本明确了针对客户新资产平台应用服务器恢复的具体分工。
台上三分钟，台下十年功
22:00，第三方把服务器安装完毕，经过漫长的等待轮到我们正式开工上场了，之前小杨在公司WIKI上准备的部署文档有了用武之地，这是我们应用服务器环境恢复的参考流程，刘博又帮我们捋了一下思路，排除一些本次系统恢复不必要做的步骤，于是最终需要做得只是一部分，而且有了之前工作积累的经验和成果，这一切使大家有信心可以很快完成。
插播一下DevOps之前的部分工作：
目前我们持续交付流水线可以实现一键发布，将资产系统的客户业务应用镜像上传到公司的私有云，这就是我们对客户的镜像仓库，在这里我们维护了每次交付给客户业务应用的不同版本，配合几个已经准备好的，放在私有云上，占用很少存储空间的启动脚本，可以提前下载到客户服务器上执行，进行统一的自动化部署，可以实现在客户服务器上完成快速部署。
简单科普一下镜像的概念，大家可以把它理解成一个不依赖于操作系统环境的业务应用的小盒子，我们可以利用若干个这样的小盒子以及它们之间形成的关系，在任何服务器和操作系统中搭建出一套一致的业务应用系统。能节省大量的问题解除过程。运行起来的镜像，我们称之为一个特定的容器。我们资产的平台是由几个不同的镜像组合而成，就像人的身体不同部位，只有共同上线成为运行容器才能协同一致工作，表现出一个完整的人的能力，缺一不可。
22:43，小邵，一位新加入DevOps团队不久，根据个人的经验以及部署文档完成平台基础环境的搭建。
23:11，小杨，一位在DevOps团队成长迅速的实习生，利用提前准备的部署脚本下载并重启所有的公司私有云镜像仓库中的资产的业务应用镜像，当这些镜像在客户服务器运行起来后，整个资产业务系统就运行起来了。
23:30，小杨在群里发了系统恢复后的新资产系统的界面截图，宣告了我们这次紧急系统恢复的成功。大家在群里简单总结了一下，互相感谢后道声晚安，结束了这次紧张的紧急恢复工作。
这次危机的解除实际工作时间仅为1.5个小时，算上前期的准备工作也就2个小时不到，这是对我们之前积累的一种自我认可，也是各位领导与团队一起协作的共同成果。
DevOps团队搭建的持续集成和持续交付流水线帮助产品研发团队轻松实现每日多次的自动化构建及发布，使得随时可以把新开发出来的功能特性交付给测试团队和最终用户成为现实，大大提升了对客户响应能力，缩短了交付反馈环，这在以前没有持续部署或发布的研发技术条件下是无法想象的。当然后面我们还有很多改进的空间。
最后，鉴于这次突发事件，我们向客户提出申请异地备份服务器，同时建议有条件的话一定要有定期的整机备份机制。
其大无外，其小无内
我们先来看个问题，企业需要实施DevOps的情况：应用上线（哪怕是改动一行代码）需要多长时间？
大家认为一般的周期通常是月、周、天、小时？如果大家发布周期在周级别，还有大量的工作靠人工执行，我们需要尽快引入DevOps了。
这是来自维基百科的解释，“DevOps是一组过程、方法与系统的统称，用于促进开发、运维部门之间的沟通、协作与整合。DevOps是提倡开发和IT运维之间的高度协同，从而在完成高频率部署的同时，提高生产环境的可靠性、稳定性、弹性和安全性。”
现在的软件开发已经不同于过去，产品要适应瞬息万变的市场，分工日益细化，一个成熟软件的规模已经不能奢望每个人成为全栈工程师能支撑得了的。尤其是对旨在于为了提高交付效率和伸缩能力的新的技术架构出现后，DevOps也随着敏捷文化的发展而融入越来越多软件组织的日常运营之中。DevOps小到掌握特定技术点，维护每个文档的细节，大到参与对研发工作规范的制定，传播对组织文化和价值观，把握DevOps的工作流程，提升软件组织的交付效能和客户满意度。涵盖从需求，开发到运维，反馈的整个过程，可以跨越团队，公司，甚至合作伙伴以及客户各方。这些都将纳入DevOps的日常工作和未来规划的视野里。
低头做事，抬头看路
应对危机，对他人而言也许是需要立刻解决的“危险”，但对DevOps而言，给了我们验证和改进工作的“机会”，是对我们平时工作积累之后的一种检验和反馈的过程，也为日后保障逐步建立一套成熟的因地制宜的流程和机制。在DevOps，我们不仅要低头做好眼前事，还要抬头看好远方路。不仅需要做好日常的事务性的工作，支持好组织的项目交付，还要建立工作规范和流程，技术能力和文档，通过具体工作支持其他团队在组织内部获得更多彼此了解的机会，更重要的是在这个过程中要做好敏捷转型的排头兵。
DevOps的长远的目标是自动化一切，监控一切，可视化一切，尽可能减少人工参与带来的不确定性从而引入更多的风险。在技术层面，我们形成持续编译、自动化测试、持续部署的能力；提升基础设施即编码的能力，将基础环境可编程化，项目团队成员可以自助获取；目前规划是先做好持续集成，持续交付和部署，根据痛点逐步优化，完善监控能力，以后还会做ChatDevOps，实现机器人值守。
简陋的笔，精彩的事
从本文开始的名言中，不难看出古代先贤也试图告诉后人：要成事，最重要的不是工具和方法，而是合适的人，只有人才能基于价值观和原则，把工具和方法运作在适配于自身企业的流程之中。这一点与敏捷宣言有异曲同工之妙。受限于我自身的笔头水平，无法详细说出这次紧急系统恢复事件中身临其境的精彩，不过无论如何我希望能尝试去记录这样一次DevOps作为主角所经历的故事。
加入DevOps团队的这段时间，我个人额外的感悟是DevOps不做人人眼中的战斗英雄或者救火队员，而是成为默默无闻的守护者。让外界感到风平浪静，才是我们作为守护者存在意义。DevOps团队大部分的时间是在为了避免发生危机而不断地思考和准备，静下来做好DevOps工作的心态应该是”行到水穷处，坐看云起时“。
—
END
感谢你阅读本文，希望能在评论区学习到大家的经验和想法~
如果对相关内容感兴趣可以关注我的公众号：捷伴行Agile。会有更多更及时的内容与君分享。