北京DevOps大会资料学习整理
今天整理下去年北京DevOps大会的资料学习情况供大家参考 。 从我们拿到的资料来看 ， 对于企业内部的微服务架构 ， DevOps和容器化实践等 ， 对于金融行业 ， 电信运营商仍然是走在前面 。 也就是原来信息化比较强的大型集团型企业往往在传统IT架构转型的时候也走在前面 ， 而相对来说很多传统行业 ， 大型的制造企业等转型较慢 ， 或者刚开始进入初步的尝试阶段 。
招商银行规模化DevOps落地实践
实际上对于企业内部的中小项目 ， 比较好的是做到对于Bug修复1到2天交付上线 ， 对于小变更一周内交付上线 ， 对于大变更2周内交付上线 。 企业信息化软件项目不要和互联网很多APP项目做比较 ， 很多互联网软件项目每天都在不断发版本 ， 在企业信息化上看并不是最佳实践 ， 更多的是应该对相关的需求范围变更进行控制 。
要做到快速交付 ， 除了开发效率 ， DevOps工具链和自动化支持 ， 另外就是一定要对原有系统进行微服务架构化拆分 ， 将单体应用转为微服务架构模式 ， 通过松耦合和组件化降低每次发布对整个业务系统的影响 。 即通过组件化后每次发布应该只部署变动的组件和模块 ， 而其它组件仍然应该保持在不变状态 。
可以看到最早的DevOps实践都是从自动构建 ， 持续集成 ， 自动化测试 ， 自动部署等开始 。
系统化的DevOps过程改进和建设往往会参考CMMI评估模式 ， 即你首先应该搞清楚DevOps成熟度模型 ， 同时结合当前企业实践现状分析当前你所处的位置 ， 然后再制定具体的改进目标和方向 ， 这个时候有了明确的目标后你才知道应该如何一步步达成目标 。
DevOps实践里面一定会涉及到以下几个方面的内容：
一个就是DevOps支撑工具链的建设 。 一个是研发项目管理和沟通协同平台 。 一个是容器化技术和自动部署 。注意在这里我们先没谈微服务架构 ， 可以理解为微服务架构和拆分不是DevOps实践一开始就必须具备的内容 。 研发项目管理涉及到版本规划 ， 需求提交 ， 研发任务分配 ， 功能开发 ， 单元测试 ， 测试和Bug修改 ， 最终版本极限和发布等关键内容 。 而这些内容需要和DevOps平台进行协同和紧密配合 。
对于招行的DevOps实践基本也体现在自动化编译构建 ， 代码静态检查 ， 自动化单元测试 ， 自动部署 ， 环境迁移 ， 镜像和制品库管理 ， 这些都和我们常说的标准的DevOps实践没有太大的区别 。 同时在DevOps实践推进过程中一定要注意的就是建立DevOps度量体系 ， 否则你实施DevOps后究竟效率提升了多少 ， 质量提升了多少等就根本无法量化 ， 无法用数据说话 。
整体来看招行的技术资料没有太多亮点 ， 也没有实质性的比较值得一说的最佳实践 。
北京移动业务支撑系统DevOps实践对于运营商基本走在了DevOps推动和实践的前列 ， 包括微服务架构和容器化技术的融合实践 ， 走在最前面的应该是中国联通的研究院和B域集中化建设过程中的DevOps推进 ， 而我们本身也在做移动项目 ， 当前移动集中化在推进过程中已经开始将DevOps支撑和微服务架构纳入到技术规范和招标要求中 。
但是整体来看 ， 集团层面的DevOps推进还是比省公司慢 ， 对于省公司侧很多年前就已经开始了容器化技术和DevOps的落地实践 。
传统企业IT架构和开发运维存在的问题分析
系统架构：新老系统并行 ， 多种架构并行 ， 多种硬件设施开发模式：多种开发模式 ， 多职能部门交叉管理 ， 缺乏统一标准发布环境：多环境部署 ， 多发布工具 ， 自动化程度低标准API：接口多样化 ， 缺少标准API集成困难注意DevOps不是新东西 ， 而是对已有的CMMI ， 研发项目管理 ， ITIL ， 敏捷开发和持续集成很多已有的研发过程管理思想的集成和融合 。 以高质量 ， 高效率 ， 高可用的业务快速交付为最终目标 ， 是唯一可以覆盖从需求到运维全过程的完整体系 。
对于北京移动的DevOps的落地实施可以看到 ， 最终重要的还是有三个关键实施阶段 ， 首先还是应该建立DevOps体系 ， 组织团队 ， 并且评估当前的成熟度并分析差距 ， 制定改进目标；其次是构建DevOps支撑工具链和支撑体系 ， 最后才是选择项目进行DevOps落地实践并持续优化改进 。
在DevOps成熟模型持续交付域本身又涉及到七个关键维度 。 即配置管理 ， 构建和持续集成 ， 测试管理 ， 部署与发布 ， 环境管理 ， 数据管理 ， 度量与反馈 。 对于数据管理为何要单独拿出做为一个维度 ， 待后面进行分析 。
对于支撑工具链要分为两大部分 ， 一个是敏捷项目管理平台 ， 一个是DevOps支撑平台
敏捷项目管理平台：重点是需求 ， 版本 ， 任务 ， 缺陷 ， 沟通协同DevOps支撑平台：重点是版本 ， 构建 ， 部署包和镜像 ， 流水线 ， 环境和环境迁移这两部分都属于支撑工具链的内容 ， 同时两部分内容本身还需要紧密协同 。 对于两者需要紧密协同和自动化的点 ， 这个将在后面专门写一篇文章来进一步说明 。
在整个私有云PaaS平台和体系构建中 ， 将DevOps变成PaaS体系中的Dev-for-Operation层 。 对于北京移动的DevOps具体实践 ， 简单的归纳总结为如下几点：
敏捷方法论：采用Scrum敏捷项目管理方法论 ， 结合用户故事和敏捷看板管理需求：采用UserStory需求条目化 ， 实现需求的端到端全生命周期管理工程实践：静态代码检查 ， 自动化部署流水线 ， 端到端混合场景测试 ， 分层测试自动化环境工具：多版本分支管理 ， 数据库持续集成 ， 自动化测试数据管理和生成整个实践里面我们还是看到诸多亮点 ， 包括了和Scrum敏捷方法论的融合 ， 需求端到端管理和闭环 ， 数据库脚本的持续集成和管控 ， 自动化测试数据的生成和管理 ， 这些实践总结和提炼都来源于最终的业务和技术需求 。
这也是我自己也一直在强调的地方 ， 即我们在DevOps推进过程中 ， 会发现整个研发项目管理流程 ， 需求流程 ， 持续集成流程中会出现流程和协同上的断点 ， 会出现未闭合情况 ， 而这些都需要我们通过相关的管理标准和支撑工具集去完善和持续改进 。 你没有真正去落地实践 ， 你往往就不会发现这些问题 。
DevOps标准认证评估权威指南及案例解读
起草单位：中国信息通信研究院、DevOps时代社区、高效运维社区、BATJ、中国移动、中国电信、中国银行、中国太平洋保险集团等
目前进展：工信部和联合国ITU-T正式立项 ， 2018年6月29发布全量送审稿
对于DevOps成熟度模型可以看到核心能力域分为三块 ， 敏捷开发管理 ， 持续交付和技术运营三个部分 。 对于敏捷开发管理和持续交付在前面都有介绍 。 对于持续运营 ， 可以看到更多的是偏ITIL方面的内容 ， 具体包括了监控管理 ， 事件和变更管理 ， 容量和成本管理 ， 高可用管理 ， 连续性管理 ， 用户体验管理几个维度 。
三级要求：在组织内全面推行DevOps实践并贯穿软件全生命周期获得整体效率提升四级要求：在组织内全面落地DevOps并可按需交付用户价值达到整体效率最优化在介绍材料里面提到企业普遍的弱项在于自动化测试 ， 数据管理 ， 数据库的持续集成上 ， 而从三级到四级 ， 实际对四级的展望主要包括了如下内容：
每天可按需多次发布上线 ， 上线操作可由开发团队完成变更前置时间：从代码提交到发布上线小时级周期时间：从需求提出到发布上线2周内平均故障修复时间：线上服务故障时1小时内能恢复服务变更失败率：线上变更导致服务不可用、服务降级或紧急修复的比例低于10%高度且全面的自动化、平台服务化作为组织能力的基础不仅仅需要持续交付的能力达到4级 ， 开发管理、技术运营也都达到3级~4级才有可能 ， DevOps是体系能力 ， 需要开发、测试、运维的全链路能力 。
注意在CMMI成熟度模型里面的四级强调的可管理级 ， 这个DevOps成熟度的四级和CMMI四级还是有差异 。 DevOps成熟度的四级更多强调的是类似发布周期 ， 故障修复实际 ， 变更失败率等量化的度量指标能否达到 ， 如果能够达到即可以说达到了四级水平 。
敏捷研发管理域
要改善个人效能 ， 那么首先你要知道你的时间究竟花在哪里了？首先要有日志记录的习惯 ， 类似很早以前就谈过的个人时间记录和个人软件过程改进等 。 你一天发现开发效率很低 ， 既可能是你本身开发熟练度不够 ， 也可能是你开发过程过程中被开会 ， 电话等打断的时间太多 。 而这些都只有你记录了时间 ， 才谈得上后面的分析 。
除了提升我们自己的生产率水平 ， 提升质量并减少返工外 。 减少等待是我们改进效能的另外一个关键点 ， 编译构建等待 ， 测试等待 ， 部署等待都 ， 而对于DevOps持续交付和自动化是有助于我们减少过程等待的 。
研发效能提升
数据驱动：分层度量 ， 效能大盘 ， 兵力分布 ， 辅助决策流程优化：产品闭环 ， 研发实践 ， 工单协同工具支撑：研发协同平台 ， 持续交付平台 ， 测试平台 ， 架构中台文化驱动：技术工程师文化 ， 团队文化 ， 企业文化 ， 敏捷文化技术运营域
在前面几篇文章已经讲到 ， 在整个DevOps能力成熟度模型和标准体系里面 ， 除了项目和开发管理 ， 持续交付 ， 测试管理外 ， 还有一个就是技术运营域 。 其中技术运营域本身重心又在IT运营和IT系统持续自动化运维上 。
DevOps关键要素：价值流 ， 部署流水线 ， 版本控制 ， 自动化配置管理DevOps强调效率：持续集成 ， 持续部署 ， 持续交付BizOps应用运维关注的是产品部署发布后的运行态 ， 而应用运维本身从上到下又包括了运行业务系统 ， 部署包容器 ， 中间件 ， 数据库 ， 操作系统 ， IT基础设施 。
你也可以理解为从上到下从应用层 ， 到服务层 ， 到中间件平台层 ， 到最终的IT基础设施资源层 。 而且各层各组件之间相互影响和制约 。 而从最早的IT资源网管监控 ， 到中间件数据库监控 ， 再到APM应用性能监控 ， 则是一个从底朝上的监控顺序 。
BizOps应用运维的关键原则
运维从立项开始 ， 交付从需求开发:即项目一开始就需要关注其是否具备可运维性非功能性需求决定了系统生命力：日志 ， 容量 ， 流控 ， 安全 ， 高性能 ， 高可用 ， 高扩展运维要有串联整个技术栈能力：流程-》应用-》中间件数据库-》操作系统-》IT基础设施理解：应用运维应该具备两个层面的串联和追溯能力 ， 其一是在某个应用功能出现明显性能问题的时候 ， 能够快速的分析出具体的代码问题 ， Sql问题或资源本身的能力问题 。 其二就是当某一个资源出现明显的性能负荷或瓶颈的时候 ， 能够快速的锁定到具体是哪一个应用功能不合理的处理逻辑或代码问题导致 。
所有应用 ， 中间件或资源的问题最终都会体现最终用户对业务系统的使用感受 。 一个优秀的应用运维应该是事先能够发现问题并提前解决 ， 而不是等用户已经暴露反馈问题后再查找原因 。
BizOps应用运维遵循IT服务管理规范
1.知识管理体系 ， 基于生产运营各项工作积累的知识、文章与文档等全生命周期管理 ， 构建嵌入各大IT服务流程与活动 。
2.IT服务流程 ， 专注于业务连续性的流程、规范、管理办法和事项 。 是一种重点化的ITIL ， 以业务连续性驱动的一系列流程管理活动 。
3.工具与平台 ， 自动化部署发布流程实现 ， 多维度的监控体系工具 ， 业务流程与应用可视化 ， 组件标准化与平台化等 ， 提供技术与工具链支撑 。
IT运维服务和技术运营
Garter认为（ITServiceManagement ， ITSM）是一套通过服务级别协议（SLA）来保证IT服务质量的协同流程 ， 它融合了系统开发管理、网络管理、变更管理、资产管理、问题管理等许多流程的理论和实践 。 ITSM以客户和服务为导向 ， 典型的系统有“CRM系统、ERP系统、决策支持系统和知识管理系统等” 。
技术运营管理过程是技术运营能力建设的一个过程 ， 包括监控管理、事件与变更管理、配置管理、容量与成本管理、高可用管理、业务连续性管理、用户体验管理等 ， 它以业务为中心 ， 交付稳定、安全、高效的技术运营服务 ， 构建业界领先的技术运营能力 ， 支撑企业的持续发展和战略成功 。
上面两个概念还是很模糊 ， 个人理解技术运营强调业务目标和保障业务连续性没有问题 ， 但是技术运营重点是运维贯彻整个IT研发生命周期 ， 从立项和需求运维就接入确保IT软件产品具备可运营和可持续运维能力 。
其次就是技术运营是一个主动发现 ， 主动监控 ， 主动发起自我优化调整的过程 ， 而不是简单额自动化运维 。 这种自我优化一方面是运维架构体系 ， 运维工具支撑的优化 ， 另外就是将可运维作为关键的非功能性需求反馈给软件产品进行后续的版本迭代优化 。
注意 ， 在DevOps标准体系技术运营里面增加了用户体验管理域 ， 其中包括了业务认知管理和体验管理 ， 在于将用户体验进一步标准化 。 不解决用户问题就不是做用户体验 ， 运维基于技术服务业务 ， 解决业务问题 ， 更像基于技术优化用户场景 ， 赋能业务场景 。
可以看下业务认知管理三级需要达到的水平如下：
1.具备能主动挖掘用户痛点需求的产品能力 ， 并能以用户单场景化系统性解决问题
2.能够联动内部产品、客服等团队,丰富统一的用户体验类的知识管理系统
3.团队定期产品岗培训,主动优化团队考核及创新性团队管理模式
搭建一个统一的DevOps支撑平台的核心目标
对产品项目
1.实时、清晰的度量研发进度、质量、风险 ， 助力研发目标精确达成
2.实现软件开发的标准化 ， 并提升版本质量
3.提升开发效率 ， 快速迭代上线 。
对团队
1.识别团队现状和水平
2.团队间 ， 团队不同时期对比分析 ， 发现问题 ， 持续改进
对个人
1.清晰工作分配和进展
2.识别个体水平和问题 ， 帮助个人成长
其它实践分析摘录
开源免费：FindBugs/FindSecBugs,SonarQube,GoogleCodeSearchDiggity商用收费：RIPS;CodeSonar;Fortify代码安全加密问题 ， 比如我们公司会采用商用的文档安全工具来实现代码安全加密 ， 在公司环境里面是明文 ， 在服务器也是明文 ， 但是拷贝出公司环境代码变成密文 。 但是一定要注意在使用代码安全后 ， 直接对我们本地代码的编译和构建效率造成了影响 。
基于二进制包的DevOps落地实践
这个不是新鲜东西 ， 相反 ， 这个应该是持续集成和DevOps中最基本的要求 。 简单来说就是只在开发测试环境进行构建编译 ， 编译构建完成的二进制部署包在后续的SIT ， UAT和生产环境进行环境迁移和动态部署 。 而不需要在后续环境重复打包 。 只有这样才能够确保我们最终测试完成的构建版本 ， 就是发布到生产环境的版本 。
要做到这点 ， 那么我们每次的版本构建都需要有详细的版本号和构建版本号 ， 同时对于测试通过的版本能够有明确的基线版本信息 。 我们最终管理的是镜像仓库的里面的部署镜像 ， 并对镜像在各个环境进行迁移 。 镜像在各个环境迁移只需要对外部的配置文件进行修改 ， 而不需要对整个项目进行重新构建 。
持续集成 ， 配合微服务架构组件化后 ， 我们必须形成一张各个组件模块在各个环境的版本信息的追踪矩阵表 ， 这追踪矩阵表可以清楚的看到当前各个组件在各个环境的最新版本信息 。 已经版本在各个环境的迁移信息 。
JFrogArtifactory
在软件项目开发中 ， 一个项目常常依赖于大量的外部库 ， 而这些外部库又在不断的进行版本更新 ， 特别是在当前微服务开发越来越流行的情况下 ， 一个服务依赖于多个服务 ， 如何管理依赖库以及依赖版本 ， 确保开发有序进行呢？
Artifactory是一款二进制存储管理工具 ， 用来管理构建构建工具（如：gradle）等所依赖的二进制仓库 ， 以方便管理第三方库和发布目标版本库 ， 从而提高软件开发效率 。 它提供大量的插件以利于和不同工具之间的整合 ， 内部使用权限管理更加安全 ， 并支持高并发等等特性 。
业务应用和非功能性容器分离
这是一个很重要的概念和实践 ， 在前面我们接收ServiceMesh的时候就谈到了Sidecar的概念 ， 而这个思路完全可以映射到我们的容器中 。 将容器分为init容器和Sidecar容器两个部分的内容 。 对于Sidecar容器重点实现部署的微服务模块的非功能性需求 ， 实现维护 ， 日志收集 ， 性能检测 ， 代理等关键能力 。
Serverless无服务器架构
无服务器架构是一种包含第三方“后端即服务”（BaaS）服务的应用程序设计方式 ， 和/或包括（FaaS）平台上的托管临时容器中运行的自定义代码 。 此类体系结构消除了对传统的始终在线服务器的大部分需求 。 这可以显着降低的运维成本 ， 复杂性以及减少项目的上线准备时间 ， 代价是增加了对供应商依赖性和相对不成熟支持服务的依赖 。
无服务器可以描述一个”富客户端+第三方云托管应用程序和服务的”的应用程序 。 这些“富客户端”应用程序一般是移动应用程序 ， 使用庞大的云端数据库或SSO服务（Auth0 ， AWSCognito等） 。 这些类型的服务以前被描述为“后端即服务” 。
Serverless无服务器架构的特点
无需管理理服务器?或者服务器?进程根据负载自动扩缩容按精确用量付费关注功能而非容量与生俱来的高可用性以函数维度按需执行代码拥抱第三方服务说了上面这些可能还是不好理解 ， 简单来说就是在在Serverless无服务器架构下 ， 更加是基于事件和函数编程无状态 ， 并基于第三方能力 。 你如何要开发一个APP应用 ， 那么这个应用本身你是不需要部署服务器端的 ， 你需要的一些服务器端能力全部来自于第三方云平台的能力提供 。 其中包括了安全认证 ， 数据存储 ， 各种技术服务能力等 。
【北京DevOps大会资料学习整理】欢迎关注@人月聊IT分享SOA ， 微服务 ， DevOps平台规划和建设 。
推荐阅读
- 甲状腺疾病|甲状腺疾病患者可以接种新冠疫苗吗？北京疾控释疑
- 北京疾控|北京疾控：甲状腺疾病患者新冠疫苗预防接种注意这些事
- 高血脂|聚焦2021CROI大会，发布多项关于日常服药引发血脂问题的研究
- 北京|北京沙尘暴的空气污染远超你的想象，它有八种方式伤害你的健康！
- ebmt|2021 EBMT大会研究进展精选，这些数据你了解吗？
- 诺如病毒|【北京疾控提醒您】开学季！如何应对诺如病毒！
- 北京|“京黄失色”！十年最强沙尘暴为何比以往都猛一些？
- 沙尘暴|北京遭遇沙尘暴天空出现蓝太阳？网友称犹如在火星上看！专家解读
- 分享老北京炸酱面最正宗的做法，不出门就能吃到北京美食，太美味
- 沙丘鹤|极罕见！时隔8年沙丘鹤再现北京，仅有1只，在江苏江西曾出现过