事项管理
工作事项类型
解决疲于奔命而无法自拔的困境，避免计划外的工作不期而至，减少事项上的“黑锅”。
正确区分工作事项类型是合理规划实施的必要前提。
- 业务事项：开发及业务类（来自开发团队、业务等相关团队）
- 内部事项：运维类（运维基础架构、运维建设项目、运维开发项目）
- 变更事项：投产变更类（需严格把控和计划的事项，影响系统业务稳定性）
- 非计划事项：应急类（操作事故、操作问题），破坏性太强
可视化看板
直观地查看任务状态、统计任务信息 --- 工作可视化，便于控制半成品（长时间排队的破坏性）
- 看板是最有效、最简单的一种掌控状态的方式
- 所有工作可视化将能控制“半成品”数量，防止其数量超过规定限额
- 最简洁的三列“待办、在办、已办”
- 不仅是团队，也建议每个人建立自己的事项看板图
- 看板图能够有效解决时间管理方法学中的关键部分：每周管理层审核（任务排序、精简任务列表等）
- 根据历史数据得出常规工作的实际时间，高效准确预估工作
- 通过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实践准则中的方法、行为和文化
三步法（核心解决方案）
- 自动交付流(单件流、在制品、库存品、准时制、持续改进等精益制造的最佳实践)
- 快速反馈机制（技术架构、持续交付、基础设施等）
- 合作共享文化的建立（组织、文化、规范和标准等）
基本方法
- 精益看板
- 实现单件流（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系统建设消耗大量资源等问题同时存在的情况下，如何思考和解决如下问题？
- 如何找到自己的位置快速构建团队？
- 如何分解业务战略？
- 如何在高压下确定并实现业务目标？
- 如何做预算和核算？
- 如何团队协作？
- 如何解决冲突？
对接与融合（ “兵无常势，水无常态”）
- 既有的ITSM如何与DevOps对接和配合？
- 如何在ITIL的流程管理中融入DevOps实践，将传统精益生产的管理精髓应用在现代IT管理中？
- 如何在极短的时间内在资源与效果上得到平衡？
- 如何让项目和公司快速转型，相关方高效协作？
- 如何提升软文化与持续交付？