去年，经过2个月的学习和复习，把DOM（DevOps Master）的证书拿下。最近又有些朋友在问DOM的事，也有很多朋友都参加了今年的考试，所以就把去年写的总结也放出来给大家做个参考
1.为什么参加DOM考试
最早接触持续构建还是在2014年，项目中引入了Jenkins，主要用于部署应用。原来的部署方式是需要开发把war包打好，然后由测试发布的测试环境并启动，如果有SQL变更，还需要手动执行SQL脚本并由测试人员做好维护。采用了Jenkins后，测试人员可以自由的发布应用，而用是一键式的发布，感觉很神奇，就做了深入的了解。
后来随着使用的深入，在Jenkins上做了更多的集成，逐渐加入了自动触构建、静态代码扫描（SonarQube）、自动化测试脚本调用等内容，慢慢的培养了自动化流水线的理念。今年在和同事的沟通中得知有DevOps的相关认证，加之目前工作也有相关性，于是就报名了相关课程，直接奔着最高级别的DOM去（一共有三级，需要前置认证）。需要这个证书主要有三方面的需要：
- 首先当然是需要这个证书做相关的背书，现在DevOps和敏捷在业内非常流行
- 转换思维，系统的学习下DevOps下的相关知识和理论，补充到实际的工作当中去。
- 从团队的角度来看，如何更好的实施DevOps，提升团队整体的效能
2. 看书
从报名到正式上课中间，差不多有3周左右的时间可以提前看书，DOM一共有三本书需要看，每本书的侧重点也都不一样。《持续交付》主要是从软件工程的实施的角度来讲解DevOps在每个环节的注意事项，更多的是展示DevOps应该做到什么样才是比较好的。通过这本书，可以很好的衡量当下自己团队所处的层级和未来发展的目标，需要精读每个章节的内容，不管是为了考试还是学习知识体系，都需要认真的看。原则上推荐看至少两遍。
《Effective DevOps》主要是从文化地角度，讲解DevOps的团队生存土壤，建议看一遍（但是本次考试这本书的份量还是很重的，占比较高，不知道是不是随机抽题时的概率问题），看这本书一定要注意不要被自己现有的文化沉淀所迷惑。这本书中的文化更多的是在理想的情况下，DevOps应该怎么去推进，但是现在国内行业的文化还存在较大的差异。为了考试，先背着吧。后续在自身团队的实践中需要做一定的取舍和变通。
《EXIN官方白皮书》这个是EXIN官方给出的划重点内容，很薄，主要讲解了DevOps中各阶段的核心内容，背吧，没什么可讨巧的。最后还有一些模拟题，可以练一练，建议看英文原版。翻译质量堪忧...
3.上课+复习+考试
三天的线下培训课程，感谢许峰老师的精彩讲解。第一天是凤凰沙盘的练习，后两天是课程大纲的讲解。关于凤凰沙盘，之前有过总结。重点说下后面两天的学习，许峰老师主要结合自身的经验和DevOps的课程要求，详细讲解了整体的知识体系，让学员对DevOps有更好的认知。建议在上课的过程中认真听讲，结合自己的工作经验进行思考，少作笔记（书上都有），多跟着老师画一些总结性的图和流程。课后及时总结。
再说复习，先看书，再看讲义，结合讲义里提到的知识点再去翻书。讲义是整体的脉络体系，具体的细节还是需要去书中查找。练习题简单做下就好，参考意义不大。
最后的考试： 仔细读题，由于翻译的问题，有些句子读起来可能会很绕口，学会抓重点词。不确认的题目可以先做个标记，等整体做完一轮后，再回过来确认。50题120分钟，时间上足够（10分钟填答题卡就够了，因为不需要涂，只需要划个对角线就好，很快的）。最后记得检查。
4.整体收获
- 思维上的转变
不管是敏捷还是DevOps，都是基于精益的理论，目的在于消费浪费，而每个企业每个团队的浪费都不一样的，存在不同的痛点及最需要改进的点，DevOps没有最佳实践，只有适应于当前团队的具体解决方案，千万不要为了DevOps而DevOps，选择各类工具或者进行无效的度量。整体的原则只一个：阶段性的消除当前流程中最大的浪费，必要时引入合适的工具。 跳出测试看研发的全生命周期，引入更多的自动化测试工具并不一定能从全局上提升效率，团队整体的效率提升取决于当前团队流程中最大的浪费。可以做一个价值流分析（以后细讲）来判断最大的浪费在哪里。 下面两个图是映像最深的信息，分别从思想和实际交付描述了研发全生命周期中的相关内容，以后再详细展开，这里做个记录。
- 结合工作的一些思考
- 如何做更好的持续集成
当前团队已经做到了任何开发都可以快速提交代码并构建发布的SIT环境上自行验证，如果构建失败就会有邮件提醒，但是没集成自动化测试，无法保证业务不受影响。只有在UAT环境上结合接口自动化进行验证。当前存在的问题是无法有效的解决服务之间的依赖问题，SIT环境极度不稳定（开发构建的代码没有经过测试，质量较差）。
- 没有做好验收测试
团队虽然做了故事的拆解，但是没有写验收测试，并不符合invest原则，导致研发人员对需求的最终呈现存在一定的歧义，给测试带来较大的工作量。这里需要区分验收测试与测试用例的区别，已有些思路，待后续的实践
- 自动化验收测试
测试团队的工作方式已经从传统的“冰激凌”模式转换到了“金字塔”模式，把更多的精力下沉到了接口测试、服务间的集成测试，更早的介入到研发过程中，功能测试的同学更多的在实践探索性测试。但是缺陷数量还是不理想，如何更好的尝试TDD或者DDD，让缺陷在研发过程中被消灭，需要团队整体的努力。
- 版本管理（全量的版本管理控制）
根据DevOps的理念，研发过程中所有的资产都需要做版本控制和管理，期望达到的效果是在任意的新环境中，都可以快速根据版本号构建出一套完整的应用。目前还无法做到这点，主要的问题在于业务环境的依赖版本不可控，服务之间的依赖梳理困难，版本管理也存在问题（并不是所有的服务统一升级版本号，未发布的服务不升级版本号，导致无法统一的拉取一个版本。但是如果每次发布都全量升级版本号，对于未升级的服务需要做额外的处理）
