大家好，今天的话题是DevOps落地实践。看分享的题目可以看出这个分享比较空洞，所以打算先从一个故事开始，阐述一下我对DevOps的理解。对DevOps的一些认知。故事要从2009年说起，那时候刚入职系统运维岗位，日常工作比较简陋简单：每天反复敲2-3个小时的命令发布版本，因为这太无聊和乏味了。于是我下定决心说：以后不能天天做这种重复性的工作了。于是开始学习python，做自动化发布。就这样三四年过去了，自己却一直兜兜转转，停留在工具层面。直到有一天，我看到了一张类似的图片，让我印象深刻。它把一个运维能想到的一切都井然有序地管理起来，这张图最令人印象深刻的部分是基础设施即代码。为什么？当时，虚拟化的概念已经开始普及。初始化服务器时，基本步骤是：安装系统，安装基础软件，调整系统配置，就像一块蛋糕，层层叠叠。当使用infrastructureascode来做这件事的时候，可以帮助你摆脱人工操作带来的不确定性，将环境准备自动化和标准化，同时还带来另外一个好处，可以统一整个环境的管理，无论是测试环境或者UAT环境，在传统的管理方式中，往往很难统一这些环境。所以我的题目是《别人家的流水线可能长这样》。现在看第二张图。如果第一张图还是研发管理层，重点关注代码提交开发后的管理。那么这张图还包含了项目管理，涵盖了从需求到交付的全过程。接下来第三张图，这张图在各大分享会和沙龙出现过很多次，很受欢迎。从需求管理、持续集成、配置部署、监管运维，全程打通，利用各种开源工具实现。但是我为什么说“你的流水线可能是这样的”，我们一一来看：1）从需求管理到持续集成这个阶段往往是人为关联的；2）测试还是以手工测试为主，没有或只有少量3）无论是配置还是部署，都只是工具化，覆盖范围只是产线。在其他环境下，你根本做不到；4）监控但不监控，刚才老师说的Prometheus只是其中一种监控工具。如果不让这些数据产生更大的价值，不为后续的技术运营提供任何支撑，那么监控中的价值只能发挥很小的一部分；5）最后还有一个更大的问题。随着工具越来越多，因此，每次推出新工具时，都会产生学习成本。这不像是使用学习平台。工具的学习，尤其是开源工具的学习，比较离散，以前的经验很难复用。还是以Prometheus为例，你需要学习它的语法规则。对于运维来说，这是一件很正常的事情，但是如果业务研发自己加上监控项和告警项，那么他十有八九会放弃不做，因为来不及交付，而且有没有时间学习复杂的语法。这将使您很难推广。所以我开始思考每个人的DevOps实现有多么不同。幸福的夫妻多半是一样的，这是一种说法，另一种马云说：每一个成功的企业都是不同的。你认为实施DevOps是第一说法还是第二说法？我的观点可以用《三字经》中的一段话来概括：性相似，行则相距甚远。为什么我认为是这样。首先，DevOps是最佳实践和理论的集合。听了各种会议，发现理论部分基本大同小异，但是在实际执行过程中，尤其是对于中型企业或者传统企业来说。在转型过程中，每家金融公司的情况都不一样。你这样做，别人这样做，为什么？我在思考这个问题的时候，从组织、制度、流程、人四个方面做了一个简单的对比：1）你整个DevOps的实施过程是自上而下还是自下而上的过程？是做整体规划，还是从运维一开始就做一些优化。DevOps对运维有一种天然的推动力：解放自己。比如咖啡党说他做蓝鲸的出发点很简单，就是提升运维人员的夜生活质量。慢慢的，蓝鲸已经成长为一个完整的自动化运维平台，涵盖了运维的方方面面。而且现在很多公司更有可能从整体规划上做DevOps，因为他们有一些先例可以遵循；2)您面临的是绿地项目还是地块项目？你是从一个全新的项目开始，还是我们面对的项目都有历史包袱，尤其是金融类公司，因为生存时间长，往往在研发、运维上都有非常沉重的历史债务。可能某个系统的业务时间比你长，甚至年龄比你大，你会怎么改造这个系统；3）互联网公司往往会自己开发各种系统来支撑自己的业务。但是，由于业务的复杂性，金融公司会有很多外包的系统。这些系统的供应商技术水平参差不齐，制定规范和标准非常困难；4）强调流程或工具，这两者没有前后之分，两只手都需要掌握。然而，许多公司倾向于关注流程而不是工具。当问题出现时，他们使用强大的流程来保护它们。比如这个进程不行，我再给你加一个进程或者给进程加一个节点，继续叠加。长此以往，你会发现过程越来越重。工具的开发也需要有流程的“引导”，否则就是无脑叠加；5）最后说的是黑盒和黑盒，对于测试，有黑盒测试和白盒测试，对于运维，也有黑盒运维和白盒运维。能不能用研发的思路去解决运维问题，而不是只关心输入输出是否满足要求。这张盲人摸象的图很好的说明了大家是怎么看待DevOps的？首先，DevOps生长的土壤决定了它最终的面貌。画面中的每个人都以接触到的部位为限，描述同一物体的不同特征。比如有人把看板技术用在运维上就是DevOps，再比如有人认为基础设施即代码就是DevOps。当组织中的DevOps负责人，之前的职位、经历、经验不同，在落地的过程中也会有很大的不同。其次是文化因素，比如：1）对于开发来说，希望从他提交代码的那一刻开始，下一步就是运维或者测试。2）对于运维来说，当出现问题的时候，运维往往是蒙蔽了双眼，他们根本不知道发生了什么。这时候他们就会抱怨研发代码怎么写。这是导致双方对立的问题。3）在处理问题的过程中，开发说这么简单的问题，为什么你们的运维处理不了？4）开始搞DevOps的时候，研发说帮我做一键发布。这可能是最终目标。对于刚开始做DevOps的同学来说，这个挑战太大了，很容易打击信心。5）对于刚开始探索DevOps的负责人来说，很容易陷入进退两难的境地，找几个开发人员来搞定运维开发。在组织因素层面上，也分为两部分：1）从运维人员的角度，第一，他认为DevOps是一种趋势，为什么？利益驱使，其他公司做DevOps，我不做，我可能连跳槽的机会都没有；第二，他觉得外面有很多成功的案例，我们也可以成功，那我们看看有哪些成功的案例？大公司的案例只适用于中小型公司。有多少运维人员，连你整个研发团队的人都没有大公司一个运维开发团队那么多；第三，我用这套工具就能脱离苦海，没想到你只是从一个苦海转了另一个苦海。2）对于老板来说，会有完全不同的思考角度。首先，对于需要自上而下考虑的问题，必须有一个清晰的模型。这个模型不是指外面的成功案例，而是指成功背后的原因，成功背后的逻辑是什么；二是改造成本，尤其是地块项目，需要进行很多标准化改造。例如，如果制定了一个标准，你要花多少钱去改变它？是否有一个公式可以衡量将使用多少工时？考虑到风险问题，原系统运行良好，但切换到新方式后，上线时如何快速处理；第三，在市场上能不能更容易找到合适的人才，我在招四个运维开发需要整整一年，没有合适的人做事，进度会特别慢。接下来是系统因素，这个很容易理解。想象一下，无论你是参与雄安新区的建设，还是参与一线城市城区的旧城改造。你面临的挑战是完全不同的，所以最终呈现出来的效果也会有很大的不同，这里就不赘述了。接下来是流程和工具。这张图中的每一个小块都足够大家讨论一阵：你看别人都在用trunk上网，用gitlab，要不要考虑从SVN迁移到GIT等等。不同的工具结合不同的着陆方式。组织、制度、流程、人，这四个方面将决定每个企业落地的差异。但我想说，即使不一样，只要能解决现在的问题，只要能给公司带来价值和效益，就是好的。每个人虽然最后走的路不一样，但都在为企业带来价值，而且都是为了同一个目标。最后说一点小经验，是我在落地过程中总结的一些经验：1）第一个深度优先，为什么深度优先？我们首先尝试使用广度优先，我们首先使用开源工具来做应用发布工作，所有的研发团队花了大约四分之三的时间来适应这个工具。后来我们打算用自研的发布工具的时候，有的团队不接受。他说第一个很好。我建议如果研发团队对DevOps的接受度比较高的话，广度优先是没有问题的。否则，先在团队中找一个接受度比较高的小组，给大家解释一下风险和收益，然后开始实施，并且在这个小组里面实施所有可以用到的工具和流程，之后再推出去他们成熟了。这时候，你就有了一个模型。通过这种模式，其他团队会更容易接受，老板也会看到你的成功。情况下，将给予更多支持。2）建立产品虚拟团队，组织架构的改变会引起公司内部的动荡，这是很多老板不愿触碰的底线。如果只有DevOps团队或者运维开发团队在推动，往往做的不好。这时候就需要成立一个虚拟团队来推广。这是一个小提示。首先，你必须让最终的实际用户必须参与其中，并且深入去做。接下来，让这个虚拟团队的成员，尤其是核心成员固化下来，让经验和技能得以延续；最后，建议在实施过程中运用敏捷思维，因为面对实施过程中的不确定性，敏捷会让成功率更高，让团队参与度更高。3）先分后合。这对应于上面提到的虚拟团队。你为什么会有这样的经历？刚上来的时候，先做一个总体规划，然后开始大张旗鼓地实施，然后就没有了。为什么？因为你很多基础设施没有到位，无论是测试、基础设施，还是人员技能和意识。当团队的成熟度达到一定程度，彼此之间的磨合达到一定程度，再合作做DevOps，你会发现很多事情会水到渠成，你实施的速度也会更快更快。4）要有衡量标准和评价标准。做任何事都不能凭感觉说好坏。没有测量，就没有数据支持。有必要，为什么？你如何证明DevOps可以产生价值？是不是故障频率越低，每次故障处理速度越快，怎么证明？可视化上述数据，更快收到反馈。5）先刚性后优化的方法应用到整个DevOps实施过程中是非常有用的。新的流程和工具总会让人不舒服。比如以前很多节点都是通过人力供给来驱动流程的推进，但是人可以非常灵活的去准确的处理流程中遇到的问题，在登陆DevOps平台的时候，可以先确定流程，然后在该平台。如果在后续的研发和使用过程中遇到问题，那么此时就对有问题的流程节点进行优化。这比在流程讨论上浪费时间要好。还有一个就是标准和规范首先很重要，不然平台到了一定程度你会发现不对劲：研发给你提了一个需求，你根本做不来，或者你发现系统不能串联，或者发现串联的成本很高，这才知道是标准和规范没做好，成本还挺高的。最后，一定要做好风控，否则DevOps会在这个公司“消亡”或者“消失”一段时间。不仅你的领导对你没有信心，所有的研发和业务方都会失去很长一段时间。不断质疑你接下来要做的事情的正确性和能力。以上就是我实施DevOps的心得，谢谢大家。
