大象翩翩起舞：中小银行的 DevOps 之旅
作者：互联网
作者简介 自我介绍一下，我是李丙洋，我的网名是君三思。刚才邓骏说我是DevOps专家，这个称谓万不敢当，实际上是我是混DB圈的，我之前写过两本书，一本叫涂抹MySQL，一本叫涂抹ORACLE，在数据库领域还行，不过对于DevOps，我是野路子出身，这次过来主要还是多学习，顺道分享一下我们在DevOps实践的一些经验。 我目前所在的企业是重庆富民银行，是我国中西部的一家比较年轻的银行。我们行的定位是要做互联网银行，我们团队里面有很多来自于互联网体系和互联网企业的人才加入，同样，我们也大量地使用互联网企业里面常会用到的技术或者是解决方案。在我行DevOps实践过程中，我们同样也是这样，深度地应用很多互联网体系的思路或者是中间件来解决我们实际遇到的问题。
今天的介绍呢，我想主要分三个方面来讲：
-
我们为什么要做
-
我们现在已经做了什么
- 我们还会在去做什么，也包括目前持续在做的一些事情
1. 为什么要做运维自动化
首先要讲第一部分，为什么要做运维自动化？这样的系统我们不是一拍脑袋，觉着这个东西很热就做，不是这样的，讲这一个话题之前我引申远一点，我一直觉得优秀的IT人一定是懒惰的，这一个懒惰是加引号的，它不是贬义词，是一个褒义词，为什么这么讲？
1.1 传统运维支撑工作的痛点
举一个场景，比如说你是一个运维工程师，每天大量的工作，都是让你重复性地执行，那你下意识的是什么，如果你具备足够的技能，为了偷懒，就会考虑能否把手动做的事情，封装成批量脚本，原来手动敲几十条命令，现在只需要一条命令，一个懒惰的人。
假定你是一个测试工程师其实也是这样，每天做各种各样的回归，用例几乎一模一样，场景也一模一样，甚至有的时候报错都一样，很繁琐。怎么办呢？通过自动化的用例，自动化的方式调用它，你只要看一下结果，一个懒惰的人。
开发更是如此。开发人员最常见的是什么，看到别人写的工具类，一边抱怨代码写得丑陋，怎么写成这个样子；然后一边用得很爽，大量地引用，但是多数情况下他会懒的重复写一遍。或者你会发现他代码里面抽象的层次越高，反倒他的技能水平越高，就是他懒得写重复的东西，所以我一直有这样的理解，我觉得优秀的人，“懒惰”是比较具备的品质，打引号的懒惰。
讲到这儿，为什么要上自动化已经很清晰了，但是为了把这个过完，我们还是要接着往下讲。首先你看确实不容易，有痛点，我觉得这一页不能深入讲，为什么？我应该算一名IT行业的老兵，刚才有朋友过来说十多年前看过我写的书，我很感慨，岁月催人老，我干过开发，设计过架构，带过运维团队，整个开发的运维角色都参与过，像很多的痛点，比如说运维里面遇到痛点，我完全是感同身受的，我甚至连续两个通宵干过，一年前都维持这样的工作。所以痛点这个不忍再提，这个伤疤不好去揭，这一页我不详细讲。
1.2 日常运维工作
对于运维团队的朋友看到会觉得这就是我们面对的现状。这可能是其中的一方面。同时运维本身作为一个支撑的团队它也会有很多需求，有一些是外部团队给他的，比如说昨天有一个哥们找你，假定你是一个运维工程师，找你过来说，帮我升级一下系统。然后今天又告诉你说，哥们再帮我初始化一下服务器。对不起，我把这个时针往回拨一下，我描述的这个频次可能不对。应该是这样，20分钟前，有一个同事找你告诉你说帮我排查一个故障，十分钟前又有个兄弟来找你说来帮我修一个数，然后10分钟以后又有人告诉你说帮他导一个报表，然后20分钟以后等等，频次基本上这样。
所以其实响应度是这样，其实一线的工程师对他们的响应度是非常高的。一方面是外部的需求，同样我们内生也有很多的需求。比如说像这里面，随便找一个像什么日常巡检，你看马上就元旦了，能不能踏踏实实放个假呢，能不能不安排现场值守人员呢，巡检工作能不能提前做好做到位。
比如说我们一些服务的优化，会不会存在内存溢出，负载情况控制得怎么样呢，监控有没有保障到位，运维团队自身要关注，所以这里面很复杂。源源不断的，而且频度很高的外部需求就不说了。运维团队自身有很多内生的需求，这些需求，如果说我们没有比较好的流程体系，没有一个工具平台支撑，那么我们要投入多少人才能做得过来，尤其是我们现在接触到的环境，动不动服务器就成千上万台，要支撑的工作量其实非常大。尤其是有的时候，更悲催的是你找不到人。那你要把现有的团队压榨成什么样子才能支撑这些需求，都是现实的需求，这一个感觉到转化到痛点上去了，不好揭伤疤。
1.3 运维自动化的优势
因为这些原因，所以我们痛定思痛，赶紧上自动化。自动化会带来很多优势，PPT的这一页我觉得不用逐条讲，好多是网上摘抄的，我只是抽象归纳了一下。比如说减轻人员负担，提升工作效率，降低运维成本，都是实实在在的，确实会有这样的效果。
然后像可视化带来的优势也是实实在在的，比如说原来我们要登陆每一台服务器操作，整体很低效，建成自动化系统后，有一个平台，在里面点按钮，通过视窗界面去操作，肯定比手动执行命令好很多。其实还不止是这些，你看我还是花了不少的功夫，看了不少的文章写出来，然后摘抄出来这么多，其实不止这么多，我也是偷懒，我也是一个懒惰的人，随便列了几条。
效率就不详细讲了，相比肯定优势明显。服务标准化我讲一下，这个对于量化运维团队成员产出很有帮助。比如说即便同样是从事应用运维，同样一个岗位不同的人员，因为他的知识体系，技术水平，可能会导致什么呢，响应的速度有可能不一样，有的人十分钟搞定，有的人半天没结果，有的人甚至根本做不了，对不对。
自动化系统上线了之后，不管谁来执行都是一样，输出的结果肯定是保证一样的，可靠性有保障，执行的步骤必须是一样，因为都是统一封装的，不管谁执行结果必然都一样，那么运维岗的服务就有可能做成标准化。然后易管理这一块，通过平台各方面的可控性都是很强的，然后结合前面讲的这些，其实都不重要，我们只是想要把这个事情说清楚。罗列了这么多，觉得这个事做了，值得，那么接下来，Just Do IT。
2. 我们做了什么
在具体讲做了什么之前呢，我觉得有必要先讲讲我们准备怎么做。就是How的问题，我前面讲我自己不是DevOps的专家，我们是野路子，一路摸爬滚打，不知道踩了多少坑，才积累了一些经验。
首先我们觉得DevOps不是一个自动化发布的系统，其实自动化发布的过程中要实现集成，构建，布署，都是再简单不过的事情，很容易，自己写脚本都轻松搞定，所以不是那么回事。再一定也不上套工具就搞定，前面的嘉宾分享过程中也都有涉及，我也认真听了，你可以看到一个完整的DevOps流程是很复杂，那这个要做好的话，一方面我们不是基于工具，另外很大程度是要基于团队内部的情况构建适合的开发环境，建立起统一的标准，团队的这种文化，然后才有可能把这一个事情做好。
在这个基础之上，我们还是要做什么呢，我觉得有几个事情很重要，要单独提出来说，第一是标准化。你想这样一个道理，哪怕是一个非常小的企业，你要管理的服务器数量达到上千台也跟玩似的，如果每一台都不一样的话，那要怎么做呢，你可以想象，要为一千台分别打造自动化模式，他最多会帮你解决什么问题，就是布署一千种模式，或者是做一千种操作，这样重复性的事情，仅此而已，但是其实企业要维护一千种代价非常高昂，也是很不现实的。
2.1 标准化建立
所以最好的是什么，我们要先把标准建立起来，这一个标准在我们实际落地的过程中，我们主要从三个方面考虑:
-
第一个是系统基线，这一块指的是操作系统的版本，环境变量，系统安装的探针服务，甚至虚拟机的配置。我们银行目前虚拟化做得非常彻底，正处在虚拟化和容器化的过渡阶段。
在这一块我引申一下关于系统基线，我一直有这样一个理解，我觉得目前我们实现是保证生产环境的配置和测试环境，在主机层面，或者说 IaaS 的层面完全一致。比如说生产环境四核8G内存的配置，那么在测试环境也是如此。
这样有什么好处呢，首先是标准了，比如说特别是跟性能测试相关，很多时候会听到业务团队等兄弟部门来抱怨，不行啊，这个环境和生产不一致啊，怎么压测出它在生产上的实际性能表现呢，那么实施标准化以后，这类问题就不存在了。实际上，保障生产和测试完全一致本身就是个伪命题。
咱们可以想想看，即便把主机资源、存储资源配置一样了，网络结构大概率还是不一样的，甚至是不可能一样的，生产的复杂性也测试环境无论如何模拟不了的，还有一些测试场景也无法接入，考虑金融行业自身的特点，比如找人行说要建一个测试，人家理都不理你，就是这样。
标准化以后，在IaaS层面，不管是生产还是测试环境的配置完全一模一样的，这样在做比如性能压测的时候，只需要关注在这种配置下的性能拐点在哪里，比如说两核4G，或者是四核8G, 它的性能表现是什么样，它的并发，它的RT是什么样等等，考虑到生产环境一般硬件型号会比测试高一档，那么生产环境的性能就没有道理比这个低，甚至有可能比这个还高一点，这样的话，就能知道甚至为后期的弹性伸缩打下一个好基础，这是引申讲到的，就是为什么一定要做系统层的标准化。
-
我们对应用服务这一块也会做一些标准化。这里就像上面讲的JDK的版本一定是一模一样的，路径完全一样，输出的日志绝对也是完全一样。
-
关于配置和日志。其实在项目支出，或者是在很多优秀架构师加入进来之前，代码结构或者说工程结构是没法看的。比如说域名化甚至完全没有开始做，所有的连接全是IP这简直就是一个灾难。
然后我们在这一个过程中做了大量的工作，比如说像内部强制域名化，引入配置中心确保我们工程下面没有一个Properties文件，没有一个config文件，只有代码。编译打包之后，尽管没有做容器化，但是输出就是一个war包，非常干净，没有任何配置，所有的配置全部在配置中心。然后通过日志输出格式，我们会定义自己的日志规范，这些日志规范一方面是说什么情况要打LOG，什么情况打WARN。
另外关于日志输出内容，甚至时间的分隔符全部都定义得非常清楚。日志输出的路径更是如此。那么我们通过这个方式为后续做，不是今天的后续，而是我们做完这一个事情后，比如说接ELK等等都是手到擒来，特别简单。
那么标准化建立起来了之后，我们前面讲的有一千种模式，如果运气好，有可能就变成十种，你只要维护十种模版就可以了，这是最大的一个收获。
2.2 准生产环境
然后第二块，一定要有类似生产环境的预演环境，有些地方叫准上线环境，有的叫准生产环境，或者是叫预发布环境，名字不重要，其实都是一回事。
这个之前我们也踩过坑，不是在我们现有的银行，而是在以前的企业里面踩过数次坑。反正每次发布都不顺利。测试环境怎么测都好好地，在生产就是有问题，每次发布都不顺利，要不回滚，要不通宵上线，边改边上线，这种是很折磨人。而且最坑的就是折磨我们运维兄弟，因为我们就是干的人，就是被干的人，这是最坑的。
所以最好呢，无论如何，不管多难我们要把这个准生产环境建立起来，这个有什么用途呢，先保证准生产跟生产环境几乎一致，几乎的意思是它们的结构首先是一样的。这个URL路径过来是经过Nginx的转发，在准生产环境必须也是这样，或者是在FO转发的生产环境也是这样，转发的路径是怎样的，跟生产也是一样，唯一的差异是在哪里，生产环境是八节点的集群，准生产环境为了节省资源，只用两个节点，但是结构是一样，两个和八个其实不影响验证发布的正确与否，对不对，所以我们投入很大的资源，花了很多的代价，不知道有多坑，建这个环境。
好，我们把它建立起来，会发现后续的上线会容易很多，就是上生产会顺利很多，因为上线方案不严谨的问题可以在准生产环境就暴露。不过准生产环境中发布还是有坑，不过这套环境好在可以白天做，这样就不用通宵了，所以也是非常重要的因素，不管花多大力，一定要建立准生产环境。
2.3 版本管理的策略
这是我前面讲的，甚至包括开发的模式，团队组成的模式都要跟着变，什么意思，我们举这样一个例子，不管用什么管理工具，是什么都不重要，最起码要关注这样一个问题，开发人员提测的版本和测试人员的版本是不是一个版本。
测试人员测过的版本和投到生产的版本是不是一样，有没有一种机制来保障，怎么去保障它。不要提容器，因为容器方式不一样，所以我们也是为什么要上容器，容器确实是解决了好多的问题，但是在一开始没有干成容器的时候，现实的问题就遇到了。
比如说说同样基于版本，其实围绕版本开发有几种理念。一种是基于分支，或者叫基于主干或者Trunk的方式做开发，始终基于Trunk开发，会面临什么时候打上线包，打了上线包之后，在变更的过程把它识别出来。同样地，如果说基于分支做开发，那么什么时候合并代码到主干去。如果一直不合并，那么它所引出的负面的效果能不能接受等等。
那么我们在做自动化的时候，要把这些层面的问题解决，如果没有解决，就会发现路走不顺。在我们团队中还有一些在用SVN，其实我个人强烈推荐使用GIT，GIT确实提供了很大的便利。我们目前的版本管理和分支管理的策略也是基本沿用GIT FLOW的这种形式，当然做了适当的删减，我们没有这么多层，没有这么复杂，或者是每一个版本都没有这么复杂，是做了适度裁剪的，但是大致是按照这个方式在做，通过版本管理的方式来去确保任意节点提交的版本一定是想发布的版本，不管它是哪个环境里面。
2.4 制度管理
有一些跟技术无关的，就是你的制度要跟上，你的流程、规范、约定、管理办法等，该出台要配套做出来，这样在实施阶段有法可依。当然有法不依，或者是违法不究这是另外的问题，但是首先要确保有这样的制度，要求他们去遵循，只是提醒一下，制度也要跟上，尽管这是非技术的问题。但是有的时候管用。
好，然后基础建完之后，我们传统的这个发布，假如不是金融体系，其实好多事情也很简单。比如说最传统的发布方式就是这样，有一个物料库，在版本库里面，然后从版本库里面拖代码下来，然后做编译，然后做构建，接下来做部署，其实都很简单，整个过程也基本上实现，很简单的方式。比如说基于Jenkins可以实现持续的布署等等，这是一个最简单的模式，它只管发布。
但是仅仅从发布来看的话，就会发现金融行业很不一样。为啥，这个行业有些特点，先不看下面，就是一般金融有三张网的说法，互联网，办公网，还有生产网，三网是完全隔离的，这个就很坑，也就是说测试环境是肯定连不到生产。
那怎么办呢，在我们这一个环境里面，左边的部分，这个测试的环境其实跟传统的场景没有什么区别，就是还可以那样玩，怎么做都可以。然后呢，我们会在我们DMZ区有一个制品库。
最重要的，因为我们是数据中心，我们是保障生产的，我们更关注的是右边，右边呢，我们的发布系统就会从制品库里面出货，制品库用什么实现都不重要，可以是一个FTP服务器，可以是一个HTTP服务器，可以是一个源码服务器等等。是什么并不重要，就是只要告诉物料在哪里，然后在右边通过发布系统布署出去，然后自动实现一系列的功能。所以这就是我接下来要讲的真正的干货。
2.5 系统的架构
目前我们银行所使用的系统，有自研的，也有第三方开源的。这个系统是自研结合第三方开源组件，这里分三个重要三个部分：
一个是逻辑层，逻辑层可以把它理解为控制台。我们把自己最关注的，或者是为了使用过程中用得爽，为了减化工作，体现我们是一个懒惰人的这部分的工作全部放在部署逻辑里面，把它封装起来，然后尽可能简化我们要做的每一步操作，说得更直观一点，就是点按钮，点这个还是点那个。然后呢，但只依靠它不行，为什么，它需要一些外部依赖，比如说它要连物料库，要有账户统一管理的平台，要做调度，要连日志等等，所以它会有一系列的依赖服务。
然后具体部署的时候，我们在下层有一个部署服务，布署服务目前基于Jenkins，其实这一层不重要，用Jenkins也好，用Ansible，或者SaltStack都可以，我们为什么选择使用Jenkins，最主要的原因是我们团队对Jenkins最熟悉，我觉得这一点也很重要，就是在选型的时候选择自己比较熟悉的平台，熟悉的解决方案，特别是当你解决有无阶段问题的时候，等后续要解决优劣的时候可以综合考虑更优的方案，解决有无的阶段，建议怎么快怎么来，怎么熟悉怎么来，这个时间不能莽撞，不能为了适应潮流，或者是盲目体现我们的新颖，盲目引入一些新东西，金融行业生产环境的敬畏是要在的。我们基本上的系统架构会是这样。
考虑系统仍处在快速迭代的周期，构建的时候呢，主要着重关注两方面：
-
第一是发布，就是前面讲的自动化的控制这部分。功能不列举。
- 第二是巡检，更多帮助我们解决自动化日常工作的这些问题。还有最基础的系统管理等等。
然后还有原型设计，原型设计这一块其实还要讲一下，里面还是有一些很有意思的小细节，比如说发布计划管理等，不是界面怎么样，而是说像管理发布计划等等，就是会有一些我们考虑的小的细节在里面。
在具体发布功能方面来看，我们更多考虑生产环境，完全不关注非生产环境的情况，因为我们的制品库的来源很简单，来源就是一个FTP仓库，或者是给我就是个地址，或者是个仓库的地址。发布功能在实现方面也可以很简单。
整体发布就是说要先选应用，要发布什么样的系统，然后选版本，要发布的是哪一个，接下来选发布到哪个服务器，最后是执行动作，是发布还是停止服务。这里有一些细节的东西，有的时候我们遇到不是这一些动作，他只是想把这个包放在服务器的某个位置，别的什么都不做，这类的场景都有考虑。所以在发布上面会根据企业的实际情况实现对应的功能。
这个是我们自研发布系统的截图，这里应该是分辨率的原因，原图是很清晰的。比如说中间日志这一块，我们可以快速查看三类的日志，一个是 Jenkins 的日志，这个日志就是可以看到部署的过程，因为自身有Jenkins输出。然后也要看外部容器的日志，这个信息会告诉我们tomcat容器启动的情况怎么样。
然后我们日志的规范，这个约定的里面呢，所有的输出不会直接输到Kibana，而是到自己定义的额外路径，所以应用系统工作是否正常，也有另外的应用日志的路径。即便查日志都有不同的方式，看起来有点繁琐，但实际用起来会发现很爽的，解决了操作过程中的实质痛点，要看什么点一下，一下就出来，特别的高效，用起来会有这样的感受。
我们给这套系统起了个很好的名字叫泰坦，内部还很响亮，外部不响亮，那我们持续做，我觉得后面持续迭代一段时间后，有可能外部也会觉得这是一个好系统。
2.6 自动化发布和运维
讲到这里，废话基本说完了，下面要进入最关键的环节了，我觉得我们做的这一部分，如果单纯看这一块的话，其实和传统的方案仍然是大同小异，没有太大的差异。这里我们额外做了什么，我们在做自动化发布系统，尤其是响应线上快速部署需求的时候，我们不仅仅要管理war包，一个的war包解决不了问题。尤其是考虑我们是一家年轻的小银行，新系统上线或发布非常频繁，上新系统要有服务器，所以我们要考虑把我们的虚拟机也管理起来。
所以研发我们的自动化运维装机系统。然后可以快速地把我们资源管理起来，提供平台化的管理能力，虚拟化底层是什么不重要，不管是vmware，不管是KVM都不重要，通过这个就可以快速初始化机器。有了机器，就能做布署吗，还不行，还要管理缓存，要管理数据库等等。
我们针对数据库方面，提供了实施数据订正的系统，为什么需要这样的系统，可以想想传统的DBA怎么样去响应需求。一个新的业务，上线前提了一串SQL语句过来，看文w发现几百K，没有打开就发现几百K，打开看一眼就预感一时半会儿根本审不完，企业的内部，尤其是像我们这种有专业DBA坐镇的企业，肯定是有严谨的数据库设计规范。但是你看一个几百K的文件，第一感觉肯定也是懵的，这个怎么看，一行一行地看，不知道要投入多长的时间，很苦恼，必然也很累。
那怎么办呢，我们通过自动化数据审计的平台，我们把内部定义的各项规范放在这个平台里面。比如说数据库设计过程中，能够使用什么样的数据类型，内部要求是什么，只使用int/varchar等等，有限的几个类型，凡不是这些类型的统统连提交都提交不了，实现的效果就是我们的DBA不会碰数据库，或者叫不到命令行模式下去执行，就到这个平台上面；
开发人员也是在这里面提交他要执行的SQL语句，不管是建库的，建表的，都在我们这个平台上去执行，系统根据定义好的规则来做合法性检测，要修改的列数行数有多少，语句有哪些不合法，不是执行会报错，执行报错肯定会报出来，也有一些不符合我们规范的会被列出来，通过这种方式简化人工要做的审核工作，那么我们的 DBA 在这个平台上面，就是流程提交，如果能够顺利提交，代表着什么，代表着通过了我们第一道初始审核，就是能够帮我们介绍大量原来靠人工，要有经验的工程师来去看、去分析的过程。
然后进入到第二环节是你的设计是不是合理，比如说索引创建了没有，或者索引创建的优不优，它主要关注这样的细节问题就可以了。对于像数据修订类型的SQL语句，DBA基本上可以不用看，直接点审核。
在这样的平台里面，工单就很重要，我们通过工单的设计，把大部分的工作授权给开发人员执行，对于运维体系的团队来说呢，他们要做的就是点审核，审核完了之后就可以执行了。
为什么这里要写两个感谢，因为一方面是底层支撑，我们团队内部有大量来自互联网体系的，我们也在深度地使用一些互联网开源的技术，就是因为我们底层实现是基于两个开源的解决方案。分别是来自去哪儿团队的mysql-inception和一个爱好者写的Yearning。inception 近期闭源了，代码在Github上已经看不到了，但是我们还是很有幸，我们接触很早，不管怎么样，这样的系统确实帮我们解决了很多问题。我们得以在它的基础上做二次开发，所以表示感谢，当然也希望他发展得更好，不管是开源和闭源我们都支持他。
然后是数据库订正，订正完了之后，还有其他的需求，比如说Redis缓存的管理，同理的，只不过我们胶片里面没有体现，我们基于是搜狐的CacheCloud去管理，同样我们不会动到系统里面去。所以从资源的申请到整个Redis缓存集群的监控等等，都会基于平台化的方式，要扩展机群，要做主从切换，都在界面点就可以了。
这些做完了之后，上线发布，或者是去投产一个新版本的时候，数据库初始化完之后，并不代表工作就完了，比如说配置也要做变更，我们前面讲了，我们引入了一个配置的中心。这里要感谢携程提供的Apollo，配置中心对于开发体系的同学大家都熟悉，我们最终选型后没有选择自研，而是基于携程的Apollo来去实现。这个配置中心呢，这里不是介绍他的功能或者给他打广告，而是介绍我们的这个理念。
我们所采用的这些中间件，不管是自研的，还是使用第三方的，我们有一个最重要的要求是什么呢，里面一定有工作流的，有工单这样的设计。就是这个事情谁来做不重要。谁来提交才重要。
提交完之后，流程走下去，怎么确保执行的结果是得到正确的响应才重要。平台来去确保，只要提交时检测是正确的，就一定能执行成功。或者是如果执行失败了，如果执行失败了，就一定会回滚成功，只有两种情况，回滚成功，或者是执行成功，一定帮你把这个信息同步出来，让操作在第一时间知晓。我们关注了这样一个层面了之后，其实大部分的工作不用再到运维人员去执行了。
我们更多关注的是什么，我们关注的是这样一个平台，需要多少人去维护它，我们的理念是运维也要全栈，一个人有能力运维全部，这是我们想做的，而不是一堆人去维护一堆的系统。就像前面讲我们说标准化，比如说你在想这样一个例子，团队要管理Oracle数据库，要管理MySQL数据库，要管理SqlServer数据库，要管理NoSQL，那只靠一个人行吗。如果不行，养四个数据库团队行吗，这个成本怎么去考量。
成本当然不是我最关心的问题，毕竟钱也不是我出，但是做为团队管理就一定要去考虑，对不对。所以一系列复杂的问题，我们想通过标准化各种各样的手段来去把工作尽可能前置，这个运维体系，或者是数据中心，人员配备再怎么多也比不上开发人员多，这中间总归有一个比例的。
比如说开发跟测试是十比三，或者是十比几，跟运维来说比例可能通常还要更低一些。那么如果我们能把前置的工作做到位，我们能把前置的资源用到位。我们的人更多做什么，我们就做平台的保障，平台来保障他的执行不出错。
只要做到这一点，谁来执行还重要吗，可以开发来执行，可以运维来执行，可以配管来执行，谁来执行都不重要，甚至审批是谁，领导来审批，领导来执行都可以。因为执行就只剩下了一个按钮，这是我们的理念，所以我们前面一系列的工作都是为了保障这一点，而不仅仅是做了一个发布。
2.7 安全审计
考虑到我们是金融体系，所以我们的保障不能有漏洞，或者有后门，有的人要搞破坏，我们也不担心，因为我们有堡垒机，我们有操作审计，我们有专业的人员以不定期的、震慑方式告诉他们，你做的每一件事情我们都知晓。
然后通过这种方式，对我们平台的推广也比较大胆地敢去运用，就是我们可以把前置授权放得更开，甚至有一些我们真是把执行的权限交到了开发团队，就是我们的响应人员，我们只是审核他要做的操作，同意了之后，所有的权限都交给具体的申请人，他可以选择在任意时间做这样的事情。那么这个时候确实对于整个支撑响应方面，数据中心的人员在这块就会轻松一些，这是我们在这方面要做的事情。
讲到这里，还有一个点，DevOps是一个持久战，就是不要期望能够通过一个工具或者是平台、软件就能解决所有的问题，肯定不是这样，一方面呢，它的主要目的是交付赋能，是为了快。于我们自身来说是偷懒，我们干得快一点，少干一点。同时呢，也要考虑企业有很多现实的情况，你看哪怕是我们成立才两年，比较的年轻的银行，实际上我们有已经开始有些历史包袱，有一些历史包袱不是我们的原因导致的。
比如说我们采用的银行软件，就是监管层面就说只能用这个，这个软件可能是十多年前开发的，开发人员都没有了，只剩下几个售前和售后，我们也没有选择，也得买啊，他们什么都不能提供改造上的支持，我们也搞不定，就是对于这一种存量要怎么去做，其实是要想一下的。所以这是一个持久化的过程，对吧。
然后DevOps需要一个需要强有力的保障团队，得有很懂行的人，还得有执行力，有推动力的人，过程中也需要一些技巧，保障思路能被贯彻下去。这是我们在这个过程中使用的工具链，这个没有什么神奇的，这里我觉得不用拍照，基本上我们用的这些都很常见，我们没有用新奇的东西，就是组合搭配，希望把它用好，仅此而已。
3. 我们接下来要怎么做
我们现在要做，以及将来要做什么，现在在做的，毋庸置疑的，其实前面的这一些截图，为什么截图没敢放太多，因为我们还很年轻，实际上我们有不少的东西都还很初级，需要持续不断地迭代完善我们这样的平台。
比如说前面介绍了一堆的系统，这也不是我们的目的，我们有一个大Platform，尽管我们线上有用户管理的系统，我们去搭建，但是其实系统很多，在操作上面有一些不便，当然比纯手工还是要高效一些，我们需要持续不断地迭代、迭代我们的软件，提高它的体验这是一方面，另外就是功能，当前我们已经迈过了从0到1，按照我们的这个理念呢，其实现在还是极大地解决了我们痛点的问题。仍然有不少新的痛点，这些痛点将来怎么做，就是我们将要面临的，就是我们这里讲的，又遇到痛点了。
发布功能仍然很弱，这个不说了，它还要持续不断地完善，同时也有很现实，也很迫切的一些需求。比如说绘图发布，或者是我们的应用系统，比如说自身不支撑多租户，但是我们处在快速上量的过程，又需要系统支持这个，支持那个，我们在现有的场景怎么做呢，把一整套的体系从基础设施，然后到上层的应用层，然后包括网络设置，全面复制一遍，重新部署一遍。即便有一些自动化的方式去支持，还是很吃力，对吧。
那么我们能不能做一些改变，如果是让应用层直接改造，当然是一种方式，但是应用层的开发团队评估后，明年12月份应该差不多，当时就很崩溃，那么现有系统的改造怎么办，求人不如求己，可能我们在这方面希望通过这种系统化工具的应用来去解决这样的问题。
然后我们的目标是什么，容器化，这一个不用讲，对，各家节奏不一样，但是其是目的一样，要上容器，怎么描述自己去想。
然后优势这个如果大家有兴趣，可以拍一下，每一个我们花了不少的心思，每个点都想过，这个效率快不说了，快很多，前面这个晓璐老师说用了会上瘾，高度认同，我们目前生产不还没有用，但是我们对容器技术很熟，我们团队的人也很熟悉。
然后使用成本就不说了，比如说容器里面，像虚拟化平台的话，生产环境能做到1:15就管理得很吃力，容器轻轻松松1:50，甚至1:200都见过，所以它的密度肯定是不一样的。那成本有可能不是我们的痛点。支持devops，像前面提的什么版本管理等等全都不存在，因为容器是基于镜像，在非生产环境打包的镜像，拿到生产环境后镜像一定还是这个镜像。
那就可以确保它肯定是同样一个版本，同样有一些痛点根本就不存在，而且考虑到像K8S这样的平台，原生提供了很多的功能，比如说灰度发布，金丝雀等，本身就已经很好用了，甚至像多机房的支持，我们自己解决起来费老劲了，找各种厂商去执行，那么基于容器云本身就已经有很好的基础了。
系统出现故障，宕了一个虚拟机，当然我们现在宕虚拟机不会怕，完全不担心，宕物理机都不怕。但是如果基于容器会更简单。宕几个节点，容器自己能帮你启动起来，都是一系列的好处。
其实这些我觉也只是阶段性的，不重要。那我们真正想做的是什么，ServiceMesh，可以去考虑这样一个问题，就是始终会有一些老旧的应用，对不对。那考虑一下我们现实的需求，比如说限流、熔断、服务发现、服务注册等等，对于一些传统应用，就是前面讲的，厂商都是十年前，哪听说过微服务，完全没戏。怎么办呢，我们完全可以跳开它，ServiceMesh就把它托管了，这样不管是什么样的系统，所以说，我们想给传统应用插上微服务的翅膀，我的分享就到这里，谢谢大家！
标签：这个,之旅,运维,一个,系统,比如说,DevOps,翩翩起舞,我们 来源： https://blog.51cto.com/15127503/2657570