C-1

• 用更少的资源完成更多的业绩，既要保持竞争力，又要削减成本

• IT 运维管理：足够的资历

• 创建最有组织、最值得信赖的团队

• 思考自己刚才了解到了什么

• 注意力集中

• 公司必须获得盈利能力

• 团队具备兑现承诺的能力

• 来自高级管理层稳定、持久的支持

• 足够的预算与人力资源

• 保持必要的“沉默”，避免做出更多愚蠢的承诺

• 负责任的公司要“照顾”好自己的员工

• 缺乏竞争力是阻碍事项达成的大敌

下属

• 你最希望我做什么？

• 最不希望我做什么？

• 可以失败，但至少不是重蹈覆辙的那种

管理者需要这样的一个人

• 可靠的、不怕告诉坏消息的人

• 自己可以信任的人去做正确的事

• 始终保持头脑清醒

• 大家觉得你可靠、务实，而且愿意表达真实想法

管理者希望

• IT 系统运行可靠有效，为业务部门提供保障

• 减少日常运维中的故障，让开发和业务部门集中精力去实现和产出

C-2

• 说服他人的能力

• 关键的联系信息

• 流程图 ---》 信息流

• 时间的安排与把控

• 敏感数据

• 任何进展的状态更新与周知

• IT 运维部门的关键流程和工具，内外部协作和沟通机制

• 本性难移

• 深思熟虑、善于分析、条理分明、客观冷静，对流程和步骤一丝不苟 --》 流程和秩序的执行者和维护者

• 开放式办公区域的对团队协作和个体效能的优劣影响

• 关注的焦点 ---》本质问题

• 谨慎承诺，技术不能解决所有问题

• “甩锅”的能力 ---》逃脱各种应负的责任

• 倾听、收集和对比关键相关人的看法

问题处理

• 以前是否遇到过类似的问题

• 易出错又危险的环节和操作

• 问题发生前的调整和改动，是否产生重大影响

• 备用方案

• 外部因素：厂商、外包、。。。

• 最坏的打算

• 业务部门如何看待这个问题

• “掘地三尺”探寻根因，对问题真正了解多少

• 问题解决的沟通协调机制、流程规范

• 问题严重等级的划分：服务中断

• 确定各相关事件的准确时间节点

C-3

• 断定故障原因的依据？为什么认定它没有引发故障？这个变更经过测试吗？

• 操作过程是否按照技术日志（步骤）在执行，符合预期结果？

• 对于跨大版本、长久时间间隔的升级，是否足够测试？

• 实施的维护窗口是否满足“变更和回退”的要求？

• 重要线索的获取途径？问题的关键？

• 严格控制紧急变更：紧急需求往往潜藏“紧急的烂摊子”

• 任何变更都必须遵循规定的程序和流程，未通知其他人的情况下展开变更，会带来极大的麻烦

• 找到关键相关人、盘问、弄清楚他们做了什么？梳理清楚故障的来龙去脉？

• 同样的错误不允许再犯

• 公司的组织架构

• 实用有效的变更系统、流程和工具：审批、授权、跟踪

• 变更管理经理：更好地了解情况，完整地掌握真实情况

• 并不是每个人只要把自己的工作完成就可以获得团体性的结果！

• 没闲工夫每出一次状况就详查一番基础性的信息！

• 准确的时间节点 --》 易于获知事件的前因后果

C-4

• 日常沟通事项的快速处理：邮件、即时通讯工具等，固定处理时间段，优先级

• “所有事情都那么重要”这不可能，也不应该！！！

• “交接环节” ---》相关人，一定要形成书面材料，明确所有关键项信息！！！

• 没有 IT 部门的参与，大部分业务项目将无法完成！

• 项目管理与 IT 部门的协作：有条不紊、客观冷静、富有责任感

• 干练的管理者

• 更短的时间、更少的经费去完成并交付更多的产品 ---》 可能性？

• 阶段的关键路径和关键人力资源，此阶段的主要任务？

• 不能再用“常规做生意的思路”来行事，来处理非常规问题，始料未及的突发事件。

• 尽管做了充分的思想准备，但还是会感到怒火中烧。

• 盛气凌人、几乎都是在指责他人的工作渎职和能力不足。

• “办公室政治”，虽然不喜欢，但也只能接收现实。

• “甩包袱”是人性的常规操作。

• 不要对任何建议抱有不切实际的“期待”。

• 管控情绪，不要轻易“拍案而起”。

• 在“落地实现”的过程中，会发现每个层面都会遇到问题。

• 要想打破“恶性循环”，就必须从源头上解决问题，才能不再疲于奔命。

• 催促他人被动去使用流程和工具，得到的结果可能只有抱怨和接口。

• 采用 ITIL（IT 基础架构库，包含很多 IT 实践和流程）而不有效落地，最终只能得到一套无人遵守的纸面好流程和工具

• 有效落地，意味着必须自上而下地贯彻执行

• 任何规避变更管理制度的相关人都将受到纪律处分

• CAB 会议：变更审计委员会，每周召开一次

• 流程设计不能坐而论道，而是需要真正去干实事 ---》 实用的流程

• 为问题解决提出解决方案，而不是成为问题的一部分，我能相信你吗？

• 如果手下的主要管理人员似乎斗得不可开交，要付出怎样的努力才能和平共处呢？

C-5

• 推脱问题，将球扔到对方半场，只是极为短暂的临时办法

• 如何建立一种互相尊重的工作关系？

• 他人的事项追踪路径？

• 内部审计与外部审计 ---》 发现和评估形势的严重性

• 账号权限管理 --》 权责分离的要求

• 怀疑他的立场与倾向

• 大部分的报告其实都“大而无用”

• 关键在于，我们在有限的时间内可以做什么，以及哪些系统是真正涵盖的？

• 会议的目的：形成共识，达成一致意见和行动，明确下一步的工作

• 办事节奏

• 如果离开某个人，团队就干不成事，那就遇到大问题了

• 真正地理解各种应用和组件如何在业务整体层面协同工作 --》 技术性全局视角

• 弄清楚究竟需要哪些资源？如何一次性申请充足资源？凭证？

• 承担的义务与所拥有的资源

• 花时间培训和帮助新人，新进人员不会产生效益，而是记过 3~6 月才能完全发挥作用

• 工作清单是怎样的？没有记录在案的工作是什么？为什么？

• 清单机制：应用系统项目、基础架构项目等等，清单会有多少个？会有多长？该怎么做才能列出？

• 对工作需求、优先等级、工作进度、可用资源、工作量估算的把控 ---》 与工作职责相对应

• 弄不清楚现有的任务，就无法有效增加和开展新任务！

• 一个简短的文字说明，描述工作是什么，以及完成这些工作需要多长时间？

• 合理争取和安排更多的资源

• 紧要任务总是在不断累加，导致原有的任务不断往后推，直到所有人都在大喊大叫，我们必须直到没有完成某项工作的真实原因！！！

• 关键人工作清单：简明扼要地列出所有工作任务、正在做什么，以及要花多长时间来完成这些任务

• 通过工作清单能够明确查人力资源的消耗和需要的人手

C-6

• 分析当前的形势，而不是一味地应对突发情况

• 开展访谈 --》 收集数据 --》 做分析

• 15 分钟访谈：以结构式交谈获取必要信息

• 人力资源在项目上的分配，各自的任务和工作余量

• 知道真相总好过一无所知

• 项目类型：内部项目、事故及故障修复工作、审计合规修复

• 关键系统缺少高可用和冗余的情况下运行，是可以避免的隐患。

• 预防性维护

• 确保将关键人力资源的精力能够投入到关键项目上，而不是在无关紧要的小事上

• 如何才能改变“游戏规则”，并获取足够的人力资源，以便恰如其分地完成所有事项呢？

• “活跃气氛，激励他人”，固执己见式的争吵只会一事无成

• 强化变更控制，一套可持续的流程和工具

• 变更计划的制定者、将要实施变更的系统、一句话概述，弄清楚“变更”的定义

• 现在建立一个有效系统之前，不断尝试，运用所有资源达成目标

• 需要一些实用的工作方法来稳妥地计划、沟通和实施，不改进方法就无法取得效果，对经验和技巧都有要求

• 面对现实，没人会真正遵守一套低效的流程

• 阻止员工去做理所应当的事，将毁掉热情与支持

C-7

• 工作视图：每周、每日

• 避免被卷入“政治旋涡”

• 目前为止，你的印象如何？如果想让一切重回正轨，你有什么计划？

• “实事求是”，摸情况，工作流程与边界

• 改进流程，从“救火模式”中解脱出来

• 只有掌握了战术，才能实现战略目标

• 你面临更严峻的问题，而这个问题与你所说的“效率”和“流程”毫无关系

• 当前的问题是，你显然并不真正理解“工作”是什么？

• 你对“工作”的定义是什么？是否达到了可以解决实际问题所需要的理解程度？ ---》对于整体组织层面的，而不是个人或管理者层面的

• 是否真实见过“工作”是如何产生、跟踪、完成、提交和统计的？

• 如果你没有真实见过与体会，那就没法去管理，更不要说组织、排序以及确保足额配备完成工作所需的资源了

• 在你对工作的内涵有更好的理解之前，任何关于控制工作的讨论都是“偏离方向”的

• “夏虫不可语冰”

• “工厂流水线的半成品、库存”现象与影响

• 半成品（WIP）是导致长期交付问题、质量问题和优先级不断调整的根源之一，是效率的隐性杀手

• 最关键的机制之一：工作任务和原材料的发布，否则无法控制半成品 ---》 工作导入量

• 有科学依据的管理运动：约束理论（TOC）、精益生产、全面质量管理

• 不应该根据第一个“工序或步骤”的效率来安排工作，而是根据瓶颈资源所能完成工作的速度。

• 在瓶颈之外的任何地方做改进都是假象，都是徒劳的！

• IT 是知识工作，很难以完全统一的工作标准、流程说明以及“严明纪律”来条框和涵盖。

• 如何确保形成一条迅速、可预测、持续不断的计划内工作流，从而交付价值同时尽可能降低计划外工作的影响与破坏？

• 稳定的、可预期的、安全的 IT 服务，为全局性的目标服务，而不是为某个部门的目标服务

三步工作法

1. 理解工作，建立快速工作流，衔接客户

2. 缩短和放大反馈环路，在源头上解决问题，避免返工

3. 建立文化，鼓励探索，吸取教训，反复实践

C-8

• 不断提醒自己，成败取决于如何沟通好这一切

• 对真正的工作需求和效能做分析评估，把工作的传递途径可视化

• 在相对完整知情的情况下，决定何人应该在何时开展何种工作

• 该做的终究都得做，谁都一样！生活是艰难的，工作也是如此！没有借口，硬上也要上！

• 关键人力资源缺少、基础架构脆弱、改进措施见效缓慢，是原因也是问题!

• 基准问题测试 --》 清楚差距与缺陷

• 工作不是变魔术，会有惊艳的呈现，而是要预演最坏的情况

• 需要有人在“头脑发热时浇冷水”，恢复一些理性思考

• 同理心，换位思考，以同感，求共识，获支持

• 80/20 法则：重点关注最有风险的变更，必须由 CAB 审核批准（每周一次的 CAB 会议，确切的议事规则与流程）

• 变更种类和等级，风险性与流程环节相匹配

• 把全局性、体系化效能问题的所有责任都压在某一方是毫无道理的

• 数据性支持：变更的时间、成功率、相关联的故障时间 --》业务部门在更全面掌握信息的情况下做出变更的决定

• 标准变更（低风险）：已经多次成功实施的变更，只需要提前批准就行

• 复杂的中等变更是否恰当地通知了所有可能受到影响的人，并获得实施许可

• 高风险的变更，密切关注问题趋势

• 流程创建和落地阶段，更应关心流程的完整性、规范性和相关方的参与面

• 不准出现未经授权的变更，也不准出现未公开的变更

• 变更冲突以及可用资源矛盾，“拥挤的空域耿一凡发生撞击事故” --》“交通管制员”必须更清楚了解情况、维持秩序

C-9

• 变更影响：明确哪些可能导致服务中断，会造成严重级别的事故

• 不能凭感觉做事，不能主观猜测和臆断

• 控制情绪：掩盖怒容，防止出现鲁莽的言辞和行为，陷入疯狂的状态

• 作为事故的处理负责人，必须首先弄清楚相关事件，尤其是相关变更的时间线

• 为基础性原则坚持态度，不软化

• 定时组织的排查故障的实战演练

• 合理解决问题的习惯

• 应急处置会议之前，从时间线上搞清楚问题的发展过程

• 对整体产生重要影响的工作，都是凸显协作效能的

• 类型工作： 业务项目、内部 IT 项目、变更

• 变更和项目的关系是什么？同等重要吗？这些变更都是从哪里冒出来的？

• 实施变更的必要性，是否支持具体项目？

• 从端到端的整体业务实现流程的全局视角来审视和思考

C-10

• 最重要的任务纲要

• 如何规避变更风险，不再为部署变更日而提心吊胆？

• 从哪种角度去理解和解释为什么有些事情未能完成？

• 进度报告、更新后的完成时间节点、资源需求

• 观察并寻求理解

• 如果一个员工“专业又聪明”“在具体事项上又显得无可或缺”，那么他大概率已经成为了一个整体效能的“瓶颈点”

• 看起来他确实是在全心投入地解决 IT 问题，但实质上已成为某些人的“私交性办公同事”，高管的“私人助理”

• “唯一一个知道问题在哪里的人”，也可能是无效忙碌的人，没有发挥关键性作用

• “他把知识和信息当成了一种权力，不愿意分享，也确实让他成为了几乎难以取代的人”

• “他解决了其他人无法处理的问题，引以自豪，但却使整个系统变得更加愚笨”

• 如何才能改正大家直接来“指派和干预”某个人工作内容和顺序的坏习惯？？？

• 必须改变工作流，流程是用来保护人和工作状态、提升整体效能的！！！

• 记录和分享，不能反复解决同一个问题，也便于日后分析

• 任何情况下，都不准做哪些无法在事后记录的事项

• 解决一个问题，知识库里就应该多一篇关于如何解决某个疑难杂症的文章，而且能够实施修复的人会越来越多。

• 为了摆脱困境，必要时采取一些极端措施

• 定义“关键人”的新流程、新职责，周知并“警告”相关人遵守

• 为什么他们认为自己的项目、自己的任务如此重要？

• 如何鼓励相关人遵守新的流程？ 加强学习、分享成就、维护名誉？

• 必须把知识全都交到真正从事这项工作的人手上，如果他们无法心领神会，那么就是责任心和技术能力出问题了。

• 必须让从事工作的人明白他们究竟在干些什么，而不是让更多人去囤积知识。

• 设法降低对“固定人”的依赖

C-11

• 变更日程表

• 为什么变更没有完成？

• 是谁批准了所有这些工作进入了系统？

• 如何对汹涌而来的工作说“不”?是否应该接受这些工作？又凭什么做出了决定？

• 我们需要更好地理解，什么工作将会成为“关键人”的头号任务？

• 确定事项的优先级、分类？确定相关的变更是什么、有多少？

C-12

• 代码在测试环境下通过各项关键检测

• 软件缺陷报告

• 配置和设置的一致性：测试环境与生产环境

• 如何配置齐备的端到端测试环境？

• 必要时，对团队和流程进行全面的管理检查

• 了解关键人对目前形势的看法？从你的角度看，事情进展得怎么样？

• 找些彻底了解那些事情的人，问问他们的想法？

• 弄清楚我们自己应该置身何处？现在的方位又是怎样的？

• 完善的软件版本：版本编号？软件包管理？

• 测试流程的可控性：终止 或 回退 ？对于临时加入内容的应对？

• 流程的“单向性”：无论是提交新代码、例行发布、文档记录，都只能是“单一入口”的！！！

• 试运行的进展情况 --》明确风险与隐患、获得建议、进行讨论

• 是否充分理解变更的可能带来的副作用和风险？

• “谁”是这场自杀式混乱的始作俑者？？？

• 事已至此，事态愈发不可收拾，糟糕程度不断突破原本的底线。此刻，别无选择，只能最后一搏，阻止这疯狂的行为！

• 需要对形势有一个全面的了解：其他相关事项的进展如何？

• 相关人都发一份摘要，尽可能地概述发生的事情，并就如何快速获取指示，形成共识和一致行动。

• 面对现实，这是一场持久战。

• 数据修改：审计轨迹、恰当地管制，保证数据的完整性和安全性

C-13

• 履行职责，意味着有问题时，挺身而出，首当其冲；面对结果时，难辞其咎，对成败负责！

• 你对整件事该负怎样的责任？ 没有人能够代替你思考和下决定！

• 要怎样才能摆脱困境、恢复正常的业务运营？

• 找到那个行事可靠、认真负责的人！

• 提交的代码必须对应某个特性或缺陷编号，没有标注的都要退回

• 限制所有影响性能的代码变更

• 很想看看他们是怎么干的，暂且观其后效，再下定论。

• 演练业务流程，了解运作情况，理解问题的严重性

• 尽我所能，当别人能够通情达理确实相信我们已经没有余力的时候，心理上其实得到了一些认可。

• 技术资源库 --》 专家组？？？

C-14

• 解决方案 --》带着实际解决方案（即使是临时性的）来汇报和沟通

• 有些时候，有些场合，说出真实想法可能会招来斥责

• 项目的梦魇：最后一刻变化的需求

• 从 IT 角度去说服业务部门去做正确的事情越来越难，谁都不愿意为不确定结果的代价买单。

• 对重大事项的可行性调查

• 敏锐的直觉 --》判断是否可以相信人？？？

• 什么样的改变？IT 行业技术日新月异，变化之快几乎很难让人跟上了，每隔几年要学的东西都几近疯狂。

• 一个人可以有几次做到把自己原有的知识全部抛下，去迎合最新的趋势？

• 最有可能搞死你的不是前期投入和搭建，而是后续永无休止的后台运行和维护。

• 工程师一直疲于应付各种故障和日常事项，根本无暇顾及根本性的改善与提升。

• 为满足多种业务和功能需求的实现和进度，正迫使我们去走“短平快”的捷径，但这些捷径正逐步导致日益恶化的整体效能。

• 迟来的真相总比永远被蒙蔽好，说真话总是“很艰难”。

• 做好应对被动地“背黑锅”的准备，总会有些人会想法设法把所有责任都推给我们

• “稀奇古怪的政治手腕”

• “宁愿虽败犹荣也不会坐以待毙”

• 与关键相关人至少保持每周一次的沟通：聚餐、聊天、碰一下想法，想一想得做些什么？

• 鼓励每个人都去露下脸，体会参与感！

• 建立人情往来，哪怕只有半小时。

C-15

• 什么是“最重要的人”? --> 工作上？生活上？

• 无论工作怎样，都应必须保持生活上的正常状态！

• 倾听来自家人的声音，不要对工作太过全神贯注，更不要陷入“心力交瘁”的状态

• 成为极少数能够兼顾家庭和事业平衡的人：养家的人（养家糊口）、家长、伴侣、突发事件的应对者

• 不得不日复一日地应付各种不可能完成的疯狂要求，这值得吗？

• 更糟糕的是，要面对很多让你厌恶甚至憎恨的“疯子”和“精致利己主义者”

• 别太有“圣人心”，我们做好本职工作便是责任心，至于拯救团队和整个公司。。。别想太多

• 预防措施：很少能明确知道究竟避开了哪些灾难？

• 问题故障：无视它们的存在是没法蒙混过关的

• 临时性的工作：计划外的工作，最具破坏性的一类工作，“救火的事情”

• 计划外工作阻碍了其他类型工作的完成：业务项目、内部项目以及变更的有序进行

• 计划外工作的破坏性以及可避免的本质

• 计划外工作是恢复性工作，几乎总是让你远离目标，知道你的计划外工作从何而来尤为重要！！！

• 想方设法采取一切必要步骤，阻止大家去做错误的工作，更确切地说，计划外的工作

• 计划外工作会让你丧失开展计划内工作的能力，必须不惜代价地根除计划外工作的最大源头！！！

• 可视化工作管理工具：着手稳定工作环境、营造工作氛围、建立快速工作流

• 管控“约束点”，提高流量，约束点可能很大程度上未被充分利用

• 约束点（瓶颈），决定了整个系统的产出

• 如果没有还清技术债务，那么随着时间推移，你遇到的问题和计划外工作量一定会不断增加。

• 别对你无法控制的事情怨天尤人。在其位，谋其政。

聚焦步骤

1. 确认约束点：对非约束点的任何改进都只是幻觉

2. 利用约束点：永远不要让约束点迁就别的资源而干等着，专注计划内事项

3. 把约束点置于次要地位：弄明白如何根据约束点来设定工作节奏，怎样有效控制约束点的工作量

• 非功能性需求：稳定性、安全性、可扩展性、可维护性、可操作性、持续性

• 那个最了解技术债务欠在哪里和如何构建代码的人，应该发挥真正的关键作用。

• 区分与业务相关或无关的工作，将无用的工作剔除系统更为重要

• 你应该知道，与实现企业目标息息相关的是什么 ---》 重要的是结果，而非过程、管理，或者你完成了哪些工作。

C-16

• 重大故障：叙述整个事件，说明过去 72 小时里的全部变更，理清故障的时间线并推理可能的原因.

• 未经批准，什么都不准碰

• 不要各种猜测，而是基于事实的推理，将时间线和数据汇总起来，进入深入的调查

• 事故调查应该井然有序，有条不紊，拿出防止再发生类似情况的办法

• 开展全员一系列全员参与的模拟事故呼叫，排演新的处理步骤

• 事故处理过程中的定时状态报告，了解进展情况

• 面对不确定因素，理清利害关系，妄下结论会将事情弄得更糟糕 --》现在最重要的是我们得了解全局

• 能告诉我你在想什么吗？局面在我掌控之中，你现在还需要什么？

• 公开透明：为团队成员开放接触上级和业务部门的渠道，是存在一定风险的

• 摆脱对某个人的强依赖

• 充分训练如何处理服务中断，考虑情况的复杂程度和不确定因素

• 和二级下属直接交换意见？ --》沟通的顺序和渠道？