【DEVOPS】Devops关键实践

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）团队不能太大

DevOps

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。