1.Devops Team的要求：非临时构造，对小区域负责，全职，跨职能，小的，多样化的专家，自组织，搭配，对正在使用的工具负责。
2.可视化工作的优点：
- 发现已经接收的工作
- 发现潜在存在容量缺乏的领域
- 哪里的资源已经或即将耗尽
- 被阻塞的任务
- 未完成的任务
- 如果没有时间完成本迭代接收的所有工作，其中哪些值得尝试去完成，以便达到最大化有用的结果
3. Kanban创建可以拉动系统：提升工作流，降低故障停滞时间，降低协调的需求
4.关于LWIP(限制在制品)：在制品数量和批量规模应该被限制
帮助构建，拉动系统；促进前置时间估算，促进可视化限制，促进持续识别，明确并消除限制；降低专业人士的工作被打断，提升由于切换丢失的生成率。降低工作时间重新规划，资源利用率的恶化。
批量规模：
提升总体总量；恶化流动节奏，提升前置时间，提升缺些数量，减缓假设评估，恶化，产品质量，提升资源利用率
5.Devops的运维需求：
- Devops扩展了产品负责人PO的角色，在整个IT运维系统中，包括功能性的以及非功能性的需求。
- 建议摒弃非功能性需求这个传统名字
- 最主要的关注点从可靠性转移到可恢复性
6. 识别处理瓶颈的方法：
采用支持LWIP限制的可视化工具，可用来识别价值流中的瓶颈
在所有瓶颈中，关注造成最大延迟的那个。
理解如何改变短期工作规则，已便于最大化用识别出来的瓶颈点
找到消除瓶颈点的办法，干掉它
撤销前面建立的短期规则，并寻找下一个显著瓶颈点。
7.与传统实践的差异占考试分数的12.5%
（1）Devops更频繁的发布（官方Devops书本上的翻译是发布是日常活动）
传统实践：大尺寸，几天，几周发布，很多资源，高付出，备份，文档，手工，时间表
Devops实践：小尺寸，每周每日发布，有效自用资源，常规付出，自动化，连续
（2）Devops更多地关注增加业务价值（官方Devops书本上的翻译是发布是由业务决定的。）
传统IT:版本发布，发布是一组共同部署到生产环境的更改，发布时间，IT决策
Devops实践：部署，使用用户完全或部分可用新功能，通过测试后立即部署，商业决策。
（3）Devops更需要自动化（官方Devops书本上的翻译是一切都是自动化的）
- 部署流水线的环境由脚本在流水线控制系统的控制下自动创建
- 这些环境会在使用后自动销毁，从而释放资源
- 流水线的快速操作需要最大可能的测试自动化
- 流水线的最后部署和分发，也是自动完成，并对系统和应用程序健康进行必要的调整。
（4）Devops处理解决事件和缺陷的方式（官方Devops书本上的翻译是缺陷立即被修复的）
- 如果要追溯的最近的部署，Devops流水线控制系统将自动回滚到之前已知稳定状态。
- Devops仍然需要人工干预来分析变化并对变化进行纠正
- Devops流水线所有链接都是已知的，包括要解决的问题，客户，开发人员和测试人员。
（5）Devops需要持续改进和保持Devops（官方Devops书本上的翻译是流程是持续更新的）
- Devops建议应立即消除所有确定的过程缺陷。
- 与可以推迟问题的传统做法相反，Devops建议尽可能多的重复有问题的步骤
- 更好的了解如何改进他们，并相应的挑战工作
8.Devops团队的理解：
（1）不是一个临时的项目团队，是一个长期存在而组建的。
（2）团队成员是全职工作在团队中
（3）是跨职能的，意味着团队应该有能力完成所负责的领域价值流上的工作。DOD完成的定义，理解的唯一方式
（4）团队不能太大
来源：CSDN
作者：心跳包
链接：https://blog.csdn.net/dop102/article/details/103994647