事项管理

工作事项类型

解决疲于奔命而无法自拔的困境，避免计划外的工作不期而至，减少事项上的“黑锅”。正确区分工作事项类型是合理规划实施的必要前提。

• 业务事项：开发及业务类（来自开发团队、业务等相关团队）

• 内部事项：运维类（运维基础架构、运维建设项目、运维开发项目）

• 变更事项：投产变更类（需严格把控和计划的事项，影响系统业务稳定性）

• 非计划事项：应急类（操作事故、操作问题），破坏性太强

可视化看板

直观地查看任务状态、统计任务信息 --- 工作可视化，便于控制半成品（长时间排队的破坏性）

• 看板是最有效、最简单的一种掌控状态的方式

• 所有工作可视化将能控制“半成品”数量，防止其数量超过规定限额

• 最简洁的三列“待办、在办、已办”

• 不仅是团队，也建议每个人建立自己的事项看板图

• 看板图能够有效解决时间管理方法学中的关键部分：每周管理层审核（任务排序、精简任务列表等）

• 根据历史数据得出常规工作的实际时间，高效准确预估工作

• 通过 backlog 可以有效安排和选取事项开展

团队运行

将团队无序忙碌、推脱抱怨的氛围转向“换位思考与合作”，增进内外部互信，提升团队效率，实现商业价值。

约束理论（Theory of Constraints，TOC）

逻辑化机构化思维过程

• 识别约束点

• 利用约束点

• 让所有其他活动都从属于约束点

• 把约束点提升到新水平

• 寻找下一个约束点

领导力障碍

团队无法达成目标的一个核心诱因是信任缺失。如果团队管理者和成员不愿面对问题，无法就众所周知的问题进行开诚布公的交流和讨论，那么将最终付出高昂的实际代价，导致严重的实际后果。

• 信任缺失：核心诱因

• 惧怕冲突：失去原则

• 缺乏诚意：模棱两可，表面赞成

• 回避问责：降低标准

• 忽视结果：对个人成就、影响和自我价值的关注超过了对团队成功的关注

精益

DevOps 思想的基础来自于“精益思想”

• PDCA 循环（Plan、Do、Check 和 Act，计划、执行、审核和落实）

• 两周改善周期

• 每两周必须做出一些改进（任何改进都可以）

• 每日重复训练一种模式的行动，养成习惯，形成天性，改变结果

建立一种持续改进的文化：鼓励探索、从失败中吸取教训，理解“反复的实践”是精通工作的先决条件。

• 制定适用于各种问题或挑战的系统化科学规程

• 组织成员普遍养成解决问题的习惯

• 周期性指导，促成角色转变

• 落地 PDCA，让成员每天慢慢进步和改变

关注系统整体表现的重要性

• 价值流控制的思维

• 如果一个系统没有改进，那么结果并非原地踏步，而是由于熵的存在，组织绩效会降低。

• 系统工作的完整性高于单项工作本身，关注整体性优化，而不是具体环节自身的优化

开发运维

• 在 IT 价值流中应用精益理论

• 信任度高的小规模团队

• 小批量规模和更小更频繁的发布

• 重视前提和基础：基础设施及代码、持续集成和持续部署、自动化

• IT 价值流自始至终拥有共同目标并共同解决问题，以服务为导向的架构体系

开发运维的价值

优化 IT 价值流和把业务需求转换为提供价值的能力和服务提高流经管理、开发、测试、交付、运维和信息安全等部门工作流的速度更强的产品可靠性需要更高频率、更可靠、更有效的变更

• 代码部署频率快

• 交付周期短

• 变更成功率高

• MTTR（mean time to repair，平均修复时间）短

置身开发运维

• IT 部门内各团队共同不懈、彼此帮助助力公司发展，高度信任、合作共事的氛围

• 重视彼此的时间和贡献，为了整体结果的实现持续学习和改进

• 对稳定性、可靠性、可用性及安全性有严格的要求

• 价值流中每个人都需要有快速的反馈回路，确保迅速发现并修复问题

• 通过有效的途径和方法把吸取的教训运用到实践中，偿还技术债务

• 像重视功能性要求一样重视非功能性要求（质量、可扩展性、可管理性、安全性、可操作性等）

• 调整工作方式，最大努力地在上班时间开展工作

一些关注点

• 类生产环境：确保内容处于可部署状态

• 功能开关：通过简单设置来完成功能启用和关闭

• 发布方式：以一种可控、可预测、可逆且压力很小的方式推出（蓝绿、滚动、金丝雀等）

• 自动化：IT 运维任务转变为自助服务（变更、配置发布和发布流程等）

有效落地

• 通过领域专家/教练评估并反思现在的工作方式，引导和帮助核心团队不断进行反思和持续改进，核心团队的每一个决策都将影响公司的状态

• 参与者对期望值、目标形成共识，运维的问题不应仅归咎于运维或 IT，而应是整个公司共同面对的问题

• 执行完整周期：实践（Doing）--》回顾（Reflecting）--》思考（Thinking）--》决定（Deciding）

• 注重技能、行为和理论结合的实践，以互动式情景来体验 DevOps 实践准则中的方法、行为和文化

三步法（核心解决方案）

1. 自动交付流(单件流、在制品、库存品、准时制、持续改进等精益制造的最佳实践)

2. 快速反馈机制（技术架构、持续交付、基础设施等）

3. 合作共享文化的建立（组织、文化、规范和标准等）

基本方法

• 精益看板

• 实现单件流（one-piece-flow）快速交付，减少在制品

• 最基本的流程优化 ---》 破茧而出

一些方法

• 激化冲突：展现真实想法和基础事实

• 迭代式演练，模拟大量工作和突发故障，精益求精

• 分享自己的经历、故事，甚至是劣势

• “由下而上” 与 “由上而下” 同样重要

• 相互培训技能，跨技能式分担工作，提高工作的扩展性

一些业界标准

审慎选取可用环节和方式应用到当前工作。

• ITIL（IT infrastructure library，信息技术基础架构库）

• ITSM（IT Service Management，信息技术服务管理）

• ITIL 和 ITSM 是支撑 IT 运维流程的最佳法则，描述了支撑开发运维协同工作的流程

• ITIL 流程很多内容需要根据实际情况实现自动化

DevOps 本质

• 始终关注企业的核心：业务价值的实现和收益

• 改变“本位主义”：责任心与敬业度的向外延展，聚焦项目群成果（MSP），提高团队默契度

• 体系一体化思维：持续关注业务、开发、测试与运维的整合，不仅是流程或工具的自动化，也会改变组织的行为文化

• 迭代式演进：持续改进与反馈，从错误中不断地学习

• 入手的三个方面（工作流的梳理和顺畅）：可视化管理、自动化流程、互信化协同

参与方

涉及相关实践、工具和思想方法众多，需要跨部门合作来打通整条 IT 价值链，端到端地实现业务价值流持续直接面对问题，深入沟通，根据实际场景来思考和解决问题

• 需要科技侧和业务侧深入协作

• 需要专家级或教练级的“画龙点睛”式点拨

• 需要管理层的深度参与，强有力的支持，无所不用其极地追求团队协作与加速价值流动

内容区分

• 不是简单的理念，而是包含管理过程、团队文化、工具支持等真正有效的实操方法

• 管理受控：工作流程（Process）、组织（Organization）、技术（Technology）、信息（Information）

核心构成

DevOps 本质是关于流、限制理论、可视化、反馈、精益、跨部门合作、组织文化等多个方面的。

• Flow（流）

• Dependency（依赖）

• Feedback（反馈）

• KanBan（看板）

• CI（持续集成）

• CD（持续交付）

• Visualization（可视化）

• TOC（约束理论）

• Automation（自动化） 《--- standardization（标准化）

• 精益（LEAN）

• 敏捷（AGILE）

• IT 服务管理流程（ITIL）

• 等等

发展阶段

• 初期：无序状态、吵架式的争辩、人人都是“部分主控者”、“攻城略地”式对团体和他人施加影响

• 中期：引导和改进，逐渐纠正到正确的轨道，探索最优模式，融合不同知识背景，引入新技术、新工具和流程

• 后期：了解行业的各种模式、见解和总结，领悟到“利用内外资源打造适合自己体系的实践”

需要思考的问题

识别--》分析--》落地--》改进：方式与途径

在跨部门合作冲突、频繁的业务需求变更、IT 系统建设消耗大量资源等问题同时存在的情况下，如何思考和解决如下问题？

1. 如何找到自己的位置快速构建团队？

2. 如何分解业务战略？

3. 如何在高压下确定并实现业务目标？

4. 如何做预算和核算？

5. 如何团队协作？

6. 如何解决冲突？

对接与融合（ “兵无常势，水无常态”）

• 既有的 ITSM 如何与 DevOps 对接和配合？

• 如何在 ITIL 的流程管理中融入 DevOps 实践，将传统精益生产的管理精髓应用在现代 IT 管理中？

• 如何在极短的时间内在资源与效果上得到平衡？

• 如何让项目和公司快速转型，相关方高效协作？

• 如何提升软文化与持续交付？