核心：价值驱动

数字化技术（信息技术）的本质目的是创造价值，它的载体是软件，提供价值的是功能特性。越早发布功能特性，便能越快创造价值。采用逐渐增加功能特定的增量式开发方法，能让我们在最等时间内开发出最小可用（MVP）产品。

围绕它周围的优秀技术实践，可以让我们开发出运行良好的软件，并且设计也是好的。这个过程需要自上而下的为之付诸行动。

源自 Ron Jeffries 的《软件开发本质论》

模式：流畅度模型

流畅度模型

数字化流畅度模型

based on: MDB & https://martinfowler.com/articles/agileFluency.html

DevOps流畅度模型

敏捷实例化

来自（《深入核心的敏捷开发》）

启动
专家
高绩效
目标：按照敏捷的方式运作起来
1. 理解 Agile、Scrum、Kanban 基础知识
2. 跟随或者照搬敏捷实践
3. 敏捷流程中的环节采用和保持
4. 各个角色明确职责以及能力要求
指标：过程性指标，比如迭代完成率； 一些 yes or no 的判断，比如可视化、story 的 Invest 原则 ，PO、BA 等角色是否 assign 等
目标：根据实际情况优化实践，完善各角色能力
1. 开始讨论不适合团队的实践
2. 理解实践背后的原则和价值观
3. 各个成员成形成一个高效整体持续改进，而不是独立个体
4. 尝试打破 Scrum/Kanban 等流程的规则
指标：过程性指标，比如 C/相关指标，质量相关指标；部分结果指标，比如 cycle time、product incident 等
目标：高绩效的自组织团队
1. 团队追求成效而非输出
打破 Scrum/Kanban 等规则，形成团队自己的规则
3. 自我探索过程中不遵守指令或者既定流程
4. 持续的以团队为中心思考和改进
指标：结果性指标，来衡量响应力、质量和交付价值
区域阶段成效借鉴典型投资时长
专注引入改变对团队工作更好的可见性；调整方向的能力团队的发展，工作流程的设计Scrum, Kanban, 非技术的 XP 实践3 - 6 个月
执行掌握实践低缺陷和高生产率技术技能学习期间的生产率变低XP, DevOps 运动6 - 18 个月
优化消除约束更高价值的交付，更好的产品决策将业务决策与专业技能转移给团队所花费的社交资本.精益软件开发，精益创业，超越预算+1-3 年
强化强化整体跨团队学习，更好的组织决策发展组织管理的新方式的时间及风险组织设计，复杂性理论迭代改进，持续进行

MDB

区域阶段组织转变转变成效典型投资（示例）时长
专注引入改变组织文化面向客户价值进行衡量和决策…...从而产生转变业务战略的需要。透明和协作带来更好的跨职能决策机制，资源能够向更高价值的工作聚焦。精益原则，IT、运维与业务的协作3 - 6 个月
执行掌握实践组织职能企业级流程、实践、技术和工具，与客户价值交付相一致。产品/服务周期时间缩短，部署更多数字服务（例如 IoT）能力的增强。频繁变更并快速获取数据的能力，促成更具适应性的商业模式。设计思维、数据战略、人才招聘、技术战略和路线图6 - 18 个月
优化消除约束组织结构关键业务能力投放在最需要的地方，模糊性和自主性影响领导力风格。价值交付的速度和技术采用的简便性带来了更高的回报，高价值的新业务模式逐步浮现。适应性领导力、产品专业知识、适应性架构、开发者体验+1-3 年
强化强化整体组织节奏新的工作方式变得制度化，但组织的迭代和持续演进成为新常态。规划通过数据自动流转、测试和验证。创新和产品卓越重塑市场，形成独特的收入模式。组织在各个方面的高响应力成为其核心能力，创造出亲密的客户互动。平台商业模式、实验文化、智能生态迭代改进，持续进行

领导变革

  1. 建立紧迫感
  2. 建立一个强有力的联盟
  3. 制定一个愿景和战略
  4. 宣传变革愿景
  5. 赋予行动权力
  6. 产生短期胜利
  7. 以变革结果为基础
  8. 巩固变革结果

能力：学习型组织

DLOQ 模型

个人层面
创造持续学习的机会
促进探寻和对话活动
鼓励协作和团队学习
使人们能够寻找共同愿景
结构层面
联系组织与其所处的环境
建立捕获和共享学习的系统
为持续学习提供战略层面的领导能力
-
获取组织性知识
提升组织的财务业绩

个人能力

源自张松的《精益软件度量：实践者的观察与思考》

ThoughtWorks Tech Lead 模型

示例见：https://phodal.github.io/tla/

团队技能图谱

学习型组织应用策略

来自《第五项修炼：学习型组织的艺术与实践》中的 8 种应用策略

  1. 学习与工作的结合
  2. 从现有条件和人力出发
  3. 学会双向交流的文化能力
  4. 建立演练场
  5. 与核心业务联系起来
  6. 建立学习型社区
  7. 与『对手』协作
  8. 开发学习型基础设施

跨职能

跨职能团队（cross-functional teams）是指把各种工作领域具有不同知识、技能的员工组合起来识别和解决共同的问题的团队。

跨职能团队的成员通常来自几个部门，任务是解决需各个部门共同协作才能解决的问题。跨职能团队可能会设计与实施质量改进方案、开放新产品和技术、提高作业效率或把各个职能部门联系起来以增强产品创新、服务创新的能力。

DevOps

DevOps（英文 Development 和 Operations 的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

DevSecOps

DevSecOps 是糅合了开发、安全及运营理念以创建解决方案的全新方法，是 DevOps 与 SecOps 的结合。 DevSecOps 的作用和意义建立在 每个人都对安全负责 的理念之上，其目标是在不影响安全需求的情况下快速的执行安全决策，将决策传递至拥有最高级别环境信息的人员。

DevSecOps 相关概念

专用安全工具

来源：《“安全需要每个工程师的参与”-DevSecOps 理念及思考》

  • SAST。静态应用程序安全测试（StaticApplication Security Testing），是指针对源代码进行静态分析从中找到安全漏洞的测试方式，有些工具也会依赖于编译过程甚至是二进制文件，通过一些抽象语法树、控制流分析及污点追踪等技术手段来提升检测覆盖度和准确度。也被称为白盒测试（White-Box Testing）。常见的工具包括老牌的 Coverity、Checkmarx、FindBugs 等，比较新的 CodeQL 和 ShiftLeft inspect。
  • DAST。动态应用程序安全测试（DynamicApplication Security Testing），是指在测试或运行阶段分析应用程序的动态运行状态。在不需要系统源码的情况下，通过模拟黑客行为构造特定的输入给到应用程序，分析应用程序的行为和反应，从而确定该应用是否存在某些类型的安全漏洞。也被称为黑盒测试（Black-Box Testing）。常见的工具包括针对 Web 应用商业和开源的 AcunetixWVS，长亭科技 X-Ray、w3af 等，也包括一些针对电脑或终端 App 等的应用。
  • IAST。交互式应用程序安全测试（InteractiveApplication Security Testing），由 Gartner 公司在 2012 年提出的一种新的应用程序安全测试方案。它的出发点是比较容易理解的，上文提到的 SAST 通过分析源码、字节代码或二进制文件从“内部”测试应用程序来检测安全漏洞，而 DAST 从“外部”测试应用程序来检测安全漏洞，它们各有优劣。
  • SCA。软件成分分析（SoftwareComposition Analysis）。如前文所指出，越发快速的开发意味着开发者要大量的复用成熟的组件、库等代码。便捷的同时也引入了风险，如果引用一些存在已知漏洞的代码版本该怎么办？如何检查他们？这衍生出了 SCA 的概念和工具。

原则：

  • 【安全左移（Shift Security Left）】
  • 【默认安全（Secure by Default）】
  • 【运行时安全（Runtime Security）】
  • 【安全服务自动化/自助化（Security as Code/Pipeline）】
  • 【利用基础设施即代码（IaC）】
  • 【利用持续集成和交付】
  • 【需要组织和文化建设】

DevSecOps 示例

DevSecOps 实施过程

  • 第一年：将安全整合到 DevOps 中
    • 不要过早下结论
    • 全面测试并建议仪表盘
  • 第二年：居安思危
    • 避免重复的基础设施建设
    • 自建或采购
    • 随攻击
  • 第三年：推动变革
    • 重新审视安全优先级
    • 迭代前进

BizDevOps

Business + Development + Operations = BizDevOps

AIOps

也就是基于算法的 IT 运维（Algorithmic IT Operations），是由 Gartner 定义的新类别，源自业界之前所说的 ITOA (IT Operations and Analytics)。

相似的有： MLOps

MLOps 是数据科学家和操作专业人员之间进行协作和交流的一种做法，可帮助管理生产机器学习生命周期。

GitOps

GitOps是一种正在流行的DevOps最佳实践，最早是由Weaveworks公司于2017年提出。它结合了基础设施即代码(IaC)，版本控制系统(通常是Git)，持续集成/持续交付(CI/CD)，将Git仓库作为声明基础设施和应用代码的唯一事实来源，并通过Pull Request(PR)来自动化地管理基础设施的开发和部署，并对整个过程的状态变化进行持续监控，审计等。

ChatOps

ChatOps 是指由对话驱动的开发。 将工具植入到对话当中，使用被关键插件和脚本改良过的聊天机器人，团队能够自动执行任务和协作，效果更好、成本更低、速度更快。

相关案例:

基于 Go 的 ChatOps 实践: 利用钉钉的企业内部机器人的回调机制，可以部署一套 HTTP 服务端来接收消息请求，根据用户定制的特定消息内容执行相应的 Git 工作流或 CI/CD 流水线。

Chat samples:

Users 命令: /pr
Robot 回复: 当前仓库的 PullRequest 列表...
          [#709] fix: typo
          [author] username

Users 命令: /jenkins test micro-server 709
Robot 回复: 开始测试 PullRequest 709
CIBot 回复: 
          [jenkins] micro-server ci
          -------------------------
          任务：#666
          状态：开始
          持续时间：0 分 1 秒
          执行人：Host 76.76.21.21

Users 命令: /approve 709
Robot 回复: 审核通过 PullRequest #709

Users 命令: /merge 709
Robot 回复: 合并 PullRequest #709
Gitee 回复: User 接受了 Owner/repo 的 Pull Request !709 fix: typo

Users 命令: /deploy micro-server
Robot 回复: 生产发布 micro-server
CDBot 回复:
          [jenkins] micro-server cd
          -------------------------
          任务：#233
          状态：开始
          持续时间：0 分 1 秒
          执行人：Host 76.76.21.21

# 友好地提供帮助
Users 命令: /help
Robot 回复: 当前支持指令列表, 带 * 需要特定人员发起
          /pr - 展示仓库发起中的 PR
          /jenkins    - 在指定 PR 下发起后端测试
          /pass  - * 测试通过指定 PR
          /approve  - * 审核通过指定 PR  
          /merge  - * 合并指定 PR
          /test  - 在仅有一个 PR 的状态下发起后端服务测试
          /deploy  - * 发布服务至生产环境
          /help - 显示此帮助内容

DesignOps

DesignOps 是对人员、流程以及工艺的编排和优化，以扩大设计的价值和规模影响。

我们如何一起工作

设计运营（DesignOps）帮助我们规划：

  • 组建：我们如何组建我们的团队?
    • 为设计团队设计组织结构
    • 创建互补，技能完备的设计团队
    • 定义个体设计师的角色，以及整个设计部门的角色
  • 协作：我们如何创建能够实现有效沟通的环境和聚会？
    • 定义常规仪式和会议的结构
    • 确保团队空间和环境有利于协作
    • 建立技能和兴趣分享实践社区
  • 人性化：我们如何确保人性化的招聘、入职和专业发展实践？
    • 设计针对设计团队需求的面试
    • 建立一致的招聘和入职实践，以建立新的团队成员取得成功
    • 同时为管理层和非管理角色制定标准化透明的发展途径

我们如何完成工作

设计运营（DesignOps）帮助我们规划：

  • 标准化：我们如何通过一致的工具集和流程提高设计质量？标准化可能包括：
    • 记录和优化高级设计流程，从启动到测试再到交付
    • 在设计过程中定义和调整有目的的设计活动
    • 审核并强制使用相同的设计工具进行有效协作
  • 协同：我们如何分享和扩展设计知识，以便我们都能使用相同的理解进行工作？协调可能包括：
    • 扩展和管理设计系统，为设计师创造效率
    • 构建每个人都可以访问的用户研究数据库
    • 使用数字资产管理器（DAMS）或其他系统在团队成员之间共享设计资产和模板
  • 优先级：我们如何决定要处理哪些项目以及何时开展工作？优先级可能包括：
    • 发现并揭示设计工作流程中的瓶颈
    • 了解设计团队的能力，以便准确估计和分配项目
    • 使用客观一致的方法来确定功能或项目的优先级

我们的工作如何产生影响

最后，设计运营（DesignOps）可以帮助我们如何思考：

  • 衡量：我们如何通过定义和衡量设计质量来使设计负责？衡量可能包括：
    • 为设计团队创建“良好”和“完成”的定义
    • 选择并调整设计质量指标，并随时跟踪这些指标
    • 在整个设计过程中创建和使用设计原则作为客观衡量标准
  • 社会化：我们如何教授他人如何设计角色和价值？社会化可以包括：
    • 制作关于设计角色和价值的一致信息，并主动与设计合作伙伴分享该信息
    • 捕获并分享以用户为中心的设计流程的成功故事
    • 认可并奖励那些将设计实践应用于其工作的团队
  • 赋能：我们如何培养对设计活动的理解和使用，即使是设计团队以外的人也是。赋能可能包括：
    • 教授设计团队以外的人员如何使用设计工具和活动
    • 创建可访问的设计活动手册，以避免设计团队作为瓶颈的挑战
    • 实施技能培训，确保正确理解和使用活动

NoOps

NoOps (no operations) 是一种理念，IT 环境可以从基础架构进行自动化和抽象化，不需要专门的团队来管理内部软件。

参考来源：什么会和“Ops”碰撞出火花？

度量模型

成熟度模型 是一种工具，可以帮助人们评估行为、实践和流程在产生预期结果方面的有效性。该模型定义了一系列的结构化级别，这些级别可以让组织沿着更系统地组织和成熟的流程的道路前进。

成熟度模型所针对的都不是简单的问题和行动，而是一系列复杂的流程与行为。

度量

度量是什么？

  • 度量是在一个特定组织上下文中形成的一系列共识。
  • 度量是将经验模型向量化模型进行匹配的尝试。
  • 度量是包含人、流程、组织和工具的一个动态系统。

度量不是什么？

  • 度量不是软件开发固有的活动。
  • 度量应该避免跟绩效直接相关。
  • 度量不是免费的。

度量软件示例

来源：《敏捷度量实战：如何度量并改进团队绩效》

工具措施度量
New Relic应用程序监控页面响应时间，运行时间，响应时间，错误率
HyperSpin可用性运行时间，响应时间
Splunk可靠性错误率，故障平时间隔时间
OWASP ZAP安全性动态分析问题
SonarQube可维护性CLOC，代码覆盖，问题，复杂性
Checkmark安全性静态分析问题

度量数据矩阵

-项目跟踪系统源代码管理CI 和部署工具应用程序监控
良好设计xxx
良好架构xxx
技术领先xxx
修改需求xxx
工作协作x
个人动机x
面对面交谈x
持续交付xx
更有效xxx
频率交付xx
软件运行x
满足客户x
简单性xx

Demo App: https://github.com/cwhd/measurementor

度量框架

来源《精益软件度量：实践者的观察与思考》。

持续改进价值效率质量能力价值命中率满意度响应速度团队产能内部质量外部质量个人团队组织识别和拆分高价值特性反馈提升价值减少没发挥价值的特性交付价值的度量响应时间的系统因素价值流图分析累积流图库存类指标度量产能提高系统效率技术债的度量开发节奏测试代码中的技术债度量呈现度量产品质量提升开发过程质量技术主动社交创造持续学习的机会促进探寻和对话活动鼓励协作和团队学习使人们能够寻求共同愿景连接组织与其所处的环境建立捕获和共享学习的系统为持续学习提供战略层面的领导力量阻碍因素

目标：

  1. 减少浪费 & JIT
  2. 质量内嵌
  3. 学习型组织

成熟度模型

  1. 初始（Initial）（混乱，临时，个人英雄） —— 开始使用一个新的或无记录的重复过程。
  2. 可重复（Repeatable） —— 至少充分记录了该过程，以便可以尝试重复相同的步骤。
  3. 已定义（Defined） —— 将流程定义/确认为标准业务流程
  4. 有能力（Managed (Capable)） —— 根据商定的指标对流程进行量化管理。
  5. 高效（Optimizing (Efficient)） —— 流程管理包括深思熟虑的流程优化/改进。

GitHub 解释版：

  • 临时（Ad-hoc） —— 新的或未记录的过程是不受控制、反应性的和不可预测的，通常是由个人驱动而没有协调或沟通。成功取决于个人英雄主义。
  • 管理（Managed）—— 流程已部分记录在案，有可能导致一致的结果。成功取决于纪律。
  • 已定义（Defined）—— 记录，标准化流程并将其集成到其他流程中。成功取决于自动化。
  • 度量（Measured）—— 对过程进行定量管理。成功取决于根据业务目标衡量指标。
  • 已优化（Optimized）—— 通过增量和创新更改，该过程正在持续可靠地得到改善。 成功取决于减少变革的风险。

技能模型

出自：Dreyfus 技能模型

  • Novice（新手）：需要指令才能工作。
  • Advanced Beginner（高级初学者）：不愿全盘思考。
  • Practitioner（从业者）：能解决问题。
  • Proficient（精通）
  • Expert（专家）：凭直觉做事

精益

——《丰田模式：精益制造的 14 项管理原则》

『4P』模式

  • 解决问题
    • 利用『改善』使组织持续学习
    • 亲临现场，彻底了解情况（现地现物）
    • 制定决策时要稳健，穷尽所有的选择
    • 并征得一致同意；实施决策时要迅速
  • 员工/合作伙伴
    • 培养深谙公司哲学理念的领袖
    • 尊重、培养并挑战你的员工和团队
    • 尊重、挑战并帮助你的供应商
  • 流程
    • 建立连续的食管炎流程以使问题浮现
    • 利用『拉动系统』避免生产过剩
    • 平抑工作量（均衡化）
    • 出现质量问题即停止生产（自动化）
    • 为实现持续改善，将任务标准化
    • 通过可视化管理使问题无所隐藏
    • 只采用可靠的、经过充分验证的技术
  • 理念
    • 管理决策以长期理念为基础，即使牺牲短期财务指标也在所不惜

知识管理

知识管理

如《知识炼金术》所说的知识分布盘点：

内部外部
个体个人总结
个体经验（隐性知识）		外部专家、顾问
其它外部人员
团体团队协作工作文档分享
团队的规则、经验与 "诀窍"
团队工作流程、制度与规范		其他团队的 "诀窍"
其他团队的经验与规则
组织知识库系统（显性知识）
约定俗成的经验或规则
公司流程、制度与规范		其他组织的知识
社会的经验与规则

SECI 模型

来自《企业知识的创造》

从……到……隐性知识显性知识
隐性知识社会化外显化
显性知识内隐化组合化
  • 社会化（socialization，共同化）：从隐性知识到隐性知识。即从人 A -> 人 B
  • 外显化（externalization）：从隐性知识到显性知识。如用语言描述
  • 组织化（combination）：从显性知识到显性知识。加工、重构等
  • 内隐化（internalization，内在化）： 从显性知识到隐性知识。由员工进行转换

PDA：知识萃取

《知识炼金术》 中提出的 PDA 模型：

准备
明确知识萃取的范围
定义知识萃取的目标与预期产出
选择匹配的知识萃取方法及人员
制订知识萃取的计划，并正式启动项目
开发
基于选定的萃取方法，规划相应的工作内容
多方位收集信息
综合、分析、提炼
快速开发原型，制订验证计划，并对其进行验证与优化
应用
基于预期产出及应用场景，进行知识成果的封装、打样，输出合适的结果
多渠道发布并立体地推广
对知识萃取项目的效果进行跟踪、评估
基于评估和业务发展，提出下一步行动建议

知识图谱

知识图谱（Knowledge Graph），在图书情报界称为知识域可视化或知识领域映射地图，是显示知识发展进程与结构关系的一系列各种不同的图形，用可视化技术描述知识资源及其载体，挖掘、分析、构建、绘制和显示知识及它们之间的相互联系。

过程：

  1. 制定知识图谱策略。从那些地方获取知识图谱数据，获取哪些数据，用怎样的方式进行加工。如人工众包
  2. 设计数据结构模型。根据知识类型的不同，设计他们的模型，及其表示关系。
  3. 编写应用进行知识转换。按任务分为概念抽取、实体识别、关系抽取等。
  4. 融合不同数据源。
  5. 补全、完善知识图谱。
  6. 展现知识图谱。如语义检索和智能问答。

原则

最小权限原则

最小权限原则，要求在计算环境的某个抽象层上，每个模块（如用户、进行或者程序）只能按照合法规定访问必需的信息和资源。

优点：

  • 更好的系统稳定性。
  • 更好的系统安全性。
  • 更易于部署

持续改进

演进式架构

源自《演进式架构》

演进式架构以支持增量的、非破坏的变更作为第一原则，同时支持在应用程序结构层面的多维度变化。
  • 增量变更。如何增量地构建软件和如何部署软件。
  • 适应度函数。架构的适应度函数为某些架构特征提供了客观的完整性评估。
  • 适当的耦合。如何确定哪些架构维度间应该相互耦合，以最小的开销和成本最大程度地获益。

常见的多个架构维度：

  • 技术。架构中的实现部分：框架、依赖的库和实现语言。
  • 数据。数据模式、表格布局、优化计划等。通常由数据库管理员（DBA）处理这类架构。
  • 安全。定义安全策略、指导方针和指定工具来帮助发布缺陷。
  • 运维与系统。关注架构如何映射到现有的物理或虚拟的技术设施中，包括服务器、机器集群、交换机、云等。

适应度函数

适应度函数是一种特定类型的目标函数，用于总结作为单个品质因数的给定设计解决方案与实现设定目标的接近程度。适应度函数用于遗传编程和遗传算法，以指导模拟向最优设计解决方案。 —— 维基百科
可审计性 :
0
可配置性 :
0
数据安全 :
0
高可用性 :
0
高吞吐量 :
0
国际化 :
0
法规要求 :
0
低延迟 :
0
可监控性 :
0
可用性 :
0

分支

  • 依赖漂移适应度函数是一项引入了特定的演进式架构适应度函数的技术，它能随着时间推移追踪这些依赖，从而能够指出可能需要的工作，以及某个潜在问题是在好转还是恶化。

适应度函数驱动编程

来源：Fitness function-driven development

架构特性

—— 《演进式架构》一书所列表的架构特性

可访问性可问责性准确性适应性
可负担性敏捷性可审计性自治性
兼容性可组合性可配置性正确性
可定制性可调试性可降级性可确定性
可信赖性可部署性可发现性分布性
有效性高效性可用性可扩展性
容错性保真性灵活性可检查性
完整性互通性可学习性可维护性
移动性可修改性模块性可操作性
可移植性精确性可预测性过程能力
可证性可恢复性相关性可靠性
重现性弹性响应性可复用性
安全伸缩性无缝性自我维持性
安全性简单性稳定性标准合规性
可持续性可裁剪性可测试性及时性

前移

前移（左移，Shifting Left）原则的核心思想是，将那些通常在较晚阶段完成的工作，尽早提前完成。

缩短反馈

  • 迭代
  • 回顾会议
  • Kanban
  • 站会
  • TDD
  • 测试

云迁移

SLA

Availability %Downtime per yearDowntime per quarterDowntime per monthDowntime per weekDowntime per day
90% ("one nine")36.53 days9.13 days73.05 hours16.80 hours2.40 hours
95% ("one and a half nines")18.26 days4.56 days36.53 hours8.40 hours1.20 hours
97%10.96 days2.74 days21.92 hours5.04 hours43.20 minutes
98%7.31 days43.86 hours14.61 hours3.36 hours28.80 minutes
99% ("two nines")3.65 days21.9 hours7.31 hours1.68 hours14.40 minutes
99.5% ("two and a half nines")1.83 days10.98 hours3.65 hours50.40 minutes7.20 minutes
99.8%17.53 hours4.38 hours87.66 minutes20.16 minutes2.88 minutes
99.9% ("three nines")8.77 hours2.19 hours43.83 minutes10.08 minutes1.44 minutes
99.95% ("three and a half nines")4.38 hours65.7 minutes21.92 minutes5.04 minutes43.20 seconds
99.99% ("four nines")52.60 minutes13.15 minutes4.38 minutes1.01 minutes8.64 seconds
99.995% ("four and a half nines")26.30 minutes6.57 minutes2.19 minutes30.24 seconds4.32 seconds
99.999% ("five nines")5.26 minutes1.31 minutes26.30 seconds6.05 seconds864.00 milliseconds
99.9999% ("six nines")31.56 seconds7.89 seconds2.63 seconds604.80 milliseconds86.40 milliseconds
99.99999% ("seven nines")3.16 seconds0.79 seconds262.98 milliseconds60.48 milliseconds8.64 milliseconds
99.999999% ("eight nines")315.58 milliseconds78.89 milliseconds26.30 milliseconds6.05 milliseconds864.00 microseconds
99.9999999% ("nine nines")31.56 milliseconds7.89 milliseconds2.63 milliseconds604.80 microseconds86.40 microseconds

部署或测试模式

部署或测试模式零停机时间实际生产流量测试根据条件向用户发布回滚时长对硬件和云费用的影响
重新创建
版本 1 已终止，版本 2 已发布。		xxx速度快，但会由于停机时间而中断无需额外设置
滚动更新
版本 2 逐步推出并取代版本 1。		✓xx慢可能需要对超额配置升级进行额外设置
蓝绿
版本 2 与版本 1 一同发布；流量在经过测试后会切换到版本 2		✓xx即时需要同时维护蓝色和绿色环境
Canary 版
版本 2 面向部分用户发布，随后全面发布。		✓✓x快无需额外设置
A/B
版本 2 在特定条件下面向一部分用户发布。		✓✓✓快无需额外设置
影子
版本 2 接收实际流量而不影响用户请求。		✓✓x不适用需要维护并行环境才能捕获和重放用户请求

DevOps 人员能力模型

维度：

可信源 :
0
可追溯 :
0
测试 :
0
规范与实践 :
0

可信源

可追溯

测试

敏捷实践

云研发

研发即代码

未来的软件开发模型（《云研发：研发即代码》）

需求
需求明确
实例化需求
需求代码化
域语言描述需求
设计
设计系统化
设计模式化
代码化设计
代码领域化
代码
开发模式化
代码领域化
需求生成代码
代码化代码
构建
持续构建
构建自动化
构建代码化
构建构建化
部署
部署自动化
提交即上线
部署代码化
部署自治
运营
运营可视化
运营中心化
代码化运营
运营需求化

架构金字塔

Architecture Level

出自：《架构金字塔》

Architecture Dashboard

C4 Model

DevOps Process