Chapter 05 - Guiding Principles

本章目标

看完本章后，你应当可以回答：

• ITIL guiding principles 的用途是什么？
• 七个 guiding principles 分别适合什么情境？
• 如何用 guiding principles 判断 PM、DevOps、AWS 的实践问题？
• 考试遇到「最佳下一步」或「最符合哪个 principle」时怎么选？
• 为什么 principles 不是口号，而是决策工具？

Key Terms

• Guiding Principles：不管组织、技术或流程怎么变，都能协助决策的共同原则。
• Focus on Value：先确认工作是否真的帮 stakeholder 创造 value。
• Start Where You Are：先看现况、数据和已有能力，再决定下一步。
• Progress Iteratively with Feedback：用小步迭代和反馈降低不确定性。
• Collaborate and Promote Visibility：让相关角色一起参与，并让真实状态可见。
• Think and Work Holistically：从 end-to-end service system 看问题，不只看单一工具或团队。
• Keep It Simple and Practical：选择足够有效、可执行、低复杂度的做法。
• Optimize and Automate：先优化流程，再自动化。

Related: Chapter 04 先把 guiding principles 放进 ITIL Value System；本章负责把七个 principles 拆开。Chapter 06 的 Four Dimensions 和 Think and Work Holistically 很容易一起考。

一句话

Guiding principles 是遇到不确定情境时的决策准则，帮助团队在不同产品、服务、技术、组织条件下，仍然能做出比较接近 value 的选择。

核心概念

Focus on Value

先问：这件事对谁创造什么 value？

这是最核心的 principle。它要求团队不要只看任务、功能、工具或流程，而要回到 stakeholder outcome。

线上服务示例：

不够好：团队要做服务状态查询页
比较好：团队要让客服查询交易时间从 10 分钟降到 30 秒

考题线索：

• 题目提到 客户 / user / stakeholder outcome
• 团队过度关注工具或流程
• 需要判断工作是否真的有 value

Start Where You Are

先理解现有状态，不要一开始就全部完全重做。

这不代表保守，也不代表不能改。它的意思是：先看现有数据、流程、能力、痛点和已经有效的东西，再决定下一步。

示例：

• 想引入 AI chatbot 前，先看现有客服 ticket 分类
• 想重构核心服务前，先看 incident log、error rate、timeout pattern
• 想改 release 流程前，先看过去失败 release 的原因

考题线索：

• 题目提到「重建整个系统」
• 没有先评估现有能力
• 最佳选项通常是先观察、评估、使用已有数据

Progress Iteratively with Feedback

不要一次做完所有东西，而是用小步迭代和反馈降低不确定性。

这个 principle 很适合处理新产品、AI、流程改善、风险高的 change。

示例：

不够好：一次把所有客服流程交给 AI chatbot
比较好：先让 chatbot 处理 10 个高频 FAQ，观察 resolution rate 和错误率

考题线索：

• 题目有不确定性
• 团队想一次做很大改变
• 最佳选项通常是小范围试行、收集 feedback、逐步调整

Collaborate and Promote Visibility

让相关角色一起参与，并让真实状态可见。

很多 service management 问题不是技术不知道怎么做，而是 stakeholder 没对齐、信息不透明、责任不清楚。

production incident示例：

• 工程知道 API timeout
• 客服不知道怎么回答用户
• 客户不知道操作是否成功
• PM 不知道 business impact

Promote visibility 不是多开会，而是让对的人看到对的信息。

考题线索：

• 团队各自为政
• stakeholder 没被纳入
• 信息不透明
• 应该建立 shared view、dashboard、沟通节奏、共同理解

Think and Work Holistically

不要只优化单一 team、单一工具或单一流程，要看整个 product / service system。

Related: 如果题目问「只看 technology 为什么不够」，通常会连到 Chapter 06 Four Dimensions。

示例：只提高 backend API speed，但客服查询流程仍然要切四个系统，整体 value 不一定提升。

AWS示例：

• 只加大 RDS instance 不一定解决核心服务 timeout
• 可能真正问题是 query、connection pool、retry、ALB timeout、frontend 重复送出、gateway latency

考题线索：

• 题目只看局部优化
• 问题横跨 people、process、technology、partner
• 最佳选项通常是 end-to-end 分析

Keep It Simple and Practical

只做足以创造 value 的必要复杂度。

这不是偷懒，而是避免为了「看起来专业」而设计过重流程。

PM Reality：

负责人：今天晚上要上正式。
错误反应：临时发明 12 层 approval。
比较好：依 change risk 决定必要检查、rollback、monitoring、沟通方式。

考题线索：

• 解法过度复杂
• 流程或工具超过实际需求
• 最佳选项通常是简单、可行、能创造 value 的做法

Optimize and Automate

先优化，再自动化。

这是考试很常见的陷阱。自动化坏流程，只会让坏结果更快发生。

示例：

不够好：直接用 AI 自动回复所有数据修正请求问题
比较好：先清理 FAQ、定义转人工规则、确认数据权限，再逐步自动化

DevOps示例：

• CI/CD 前先确认 test quality
• 自动 deploy 前先确认 rollback strategy
• 自动 alert 前先降低 noisy alarm

考题线索：

• 题目提到 automation / AI
• 现有流程混乱
• 最佳选项通常是先理解与优化流程，再自动化

PM 视角

PM 可以把 guiding principles 当成日常决策检查清单。

需求评估

• Focus on value：这个需求对谁有 value？
• Start where you are：目前数据和流程怎么样？
• Collaborate and promote visibility：谁需要参与？

Roadmap

• Progress iteratively with feedback：是否能切成可验证的小版本？
• Think and work holistically：这会影响客服、运营、财务、法务、工程吗？
• Keep it simple and practical：MVP 是否足够？

Release

• Optimize and automate：流程稳定后再自动化
• Focus on value：release 是为了什么 outcome？
• Collaborate and promote visibility：上线状态谁要知道？

Developer / DevOps 视角

Developer / DevOps 常会在以下情境用到 principles：

• Incident：先 restore value，再找 root cause
• Change：依风险决定 control，不是所有 change 都用同一种流程
• CI/CD：先优化 test、rollback、monitoring，再自动化 deploy
• Observability：dashboard 要服务 decision，不是展示所有 metrics
• Refactor：不要为了技术洁癖重写整个系统，先看现有痛点和 value

示例：核心服务 timeout

Focus on value:
先恢复用户最需要的服务能力

Start where you are:
先看 logs、metrics、recent changes

Collaborate and promote visibility:
让客服、PM、on-call 共享状态

Think and work holistically:
检查 frontend retry、backend、DB、gateway、network

Progress iteratively with feedback:
先 hotfix / rollback，再逐步改善

Optimize and automate:
incident 后再补 alarm、runbook、自动化检查

AWS 对照

Focus on Value

不要一开始就问「要用 Lambda 还是 ECS」，先问 service outcome 是什么：低延迟？高可用？低成本？快速实验？

Start Where You Are

先看 CloudWatch metrics、ALB logs、RDS Performance Insights、现有 incident pattern。

Progress Iteratively with Feedback

先在小流量或 staging 试行架构变更，不要一次全量切换。

Collaborate and Promote Visibility

让 PM、DevOps、backend、security、support 看到相同 dashboard 和 rollout 状态。

Think and Work Holistically

核心服务 timeout 不一定是 RDS 问题，可能是 gateway、retry、frontend、network、IAM、queue、connection pool 的组合。

Keep It Simple and Practical

小系统不一定需要 Kubernetes。先选足以支持 value 的架构。

Optimize and Automate

先让 release / rollback / monitoring 清楚，再做自动化 deploy 和 auto-remediation。

实践对照

假设团队想改善 production incident。

七个 principles 可以这样用：

Focus on value:
目标是降低操作失败影响，而不是增加更多 ticket 列。

Start where you are:
先整理最近 3 个月 incident、客服 ticket、CloudWatch alarm。

Progress iteratively with feedback:
先改善 top 3 问题，不要一次重做整个核心服务。

Collaborate and promote visibility:
让客服、客户运营、工程、PM 看到同一份 incident status。

Think and work holistically:
同时看 UI、API、gateway、DB、客服流程、客户通知。

Keep it simple and practical:
先补 runbook 和清楚 status message，不急着做大型平台。

Optimize and automate:
先改善 alarm noise 和处理流程，再引入自动化通知或 AI triage。

常见误区

误解 1：Guiding principles 是记忆题

考试和工作都更重视情境判断。需要知道什么情况适合哪个 principle。

误解 2：Optimize and automate 代表立刻自动化

重点是先 optimize，再 automate。直接自动化混乱流程是典型陷阱。

误解 3：Keep it simple and practical 代表随便做

它不是降低质量，而是避免不必要复杂度。该有的风险控制、security、monitoring 仍然要有。

误解 4：Start where you are 代表不要改变

它是要先理解现况，再做有根据的改变。不是保守，也不是拒绝 transformation。

误解 5：Collaborate and promote visibility 代表所有人都要参加所有会议

Visibility 是让对的人看见对的信息，不是增加会议负担。

Interview Angle

可能被问：

• Which ITIL guiding principle is most important when introducing automation?
• How would you apply guiding principles during a production incident?
• How do you avoid overengineering a release process?
• How do you decide whether to rebuild or improve an existing service?

回答方向：

• 用情境选 principle，不要只列清单
• 提到 value、feedback、visibility、holistic thinking
• 看到 automation 要说先 optimize
• 看到重建系统要说先 start where you are

Exam Tips

七个 principles 的考试判断可以用这张速查表：

题目线索	最可能的 principle
问 客户 / stakeholder outcome	Focus on value
想全部完全重做	Start where you are
大型高风险改变	Progress iteratively with feedback
团队信息不透明	Collaborate and promote visibility
只看单一部门或工具	Think and work holistically
解法太复杂	Keep it simple and practical
想直接自动化	Optimize and automate

考试常见陷阱：

• 看到 AI / automation 就直接选自动化。正确做法通常是先优化流程。
• 看到流程问题就选大量 governance。正确做法可能是简化并聚焦 value。
• 看到系统问题就选重建。正确做法通常是先理解现况。
• 看到 incident 就只找 root cause。实务上常先 restore service value。

Summary

Guiding principles 是 ITIL 中最实用、也最常考的部分之一。它们不是流程，而是决策准则。对 Technical PM 来说，七个 principles 可以直接用在需求判断、roadmap、release、incident、AWS 架构、AI 引入和流程改善。考试时不要机械记忆定义，要抓题目线索：value、现况、迭代、可视化、整体性、简化、自动化。

References

• PeopleCert - ITIL Foundation (Version 5)
• ITIL - ITIL Foundation (Version 5)
• ITIL - Foundation Version 5 What's New

Quiz

请见 Chapter 05 Quiz。