随着编写代码的成本降低，卓越的运营能力成为决胜关键。未来，软件工程师的需求将持续增长，特别是站点可靠性工程师 (SRE) 会成为最热门的职位。真正的挑战并非快速开发一个产品原型，而是确保服务能够长期稳定运行，因为用户购买的是可靠的服务，而非仅仅是软件本身。
编程容易，运维很难
编写代码从来都只是这份工作里最容易的部分。真正的难点在于如何让代码长期稳定地运行。软件工程的本质是在时间维度上进行编程，它关心的是系统如何随时间演变和变化。
人人都想开发一个全新的演示产品，但没人愿意负责运行一项服务。
从无代码和电子表格中吸取的教训
以无代码工具和电子表格为例，许多人认为这种由非专业人士为解决特定问题而构建的、用完即弃的软件是未来。
想象一个场景：
- 会计部门的乔每周需要花费 10 小时处理一项重复性工作。
- 由于无法获得工程资源，他利用无代码工具和电子表格宏，自己动手构建了一个工具，将每周 10 小时的工作缩短为 1 小时。
- 起初效果显著，但他每周都会遇到新的边界情况，需要不断进行修补。
随着时间推移，业务规则不断变化，乔被自己创造的这个“愚蠢”系统彻底束缚。他无法休假，也无法培训他人来接手，这个系统似乎永远无法正常工作。他陷入了无尽的修补和维护中，每次运行代码都充满恐惧。
“计算机病”的陷阱
物理学家费曼将这种现象称为“计算机病”。
问题在于，你会忍不住不断地修补和调整。自动化很有趣，但你可能忘了这并非必需。
自己动手改进和自动化事务的过程很有趣，但提供一项可靠、规模化且能持续数年的服务却一点也不好玩。而这，恰恰是人们愿意花钱购买的服务所需要具备的特质。
为什么运营卓越是未来
用户购买的是服务，而不是软件。 好的软件应当是“隐形”的。
你并不关心 iCloud 的工作原理，只希望照片能自动出现在所有设备上。你也不关心支付终端和银行之间如何通信，只希望自己能顺利买到咖啡。
实现这种“隐形”体验需要大量工程工作。开发一个可用的演示版本，或许只完成了最初 90% 的工作，而真正关键的是后面那 190% 的努力。
这才是真正困难的工程挑战：
- 你的正常运行时间是多少？缺陷率有多高？
- 从故障中恢复的速度有多快？是主动发现问题还是等用户报告？
- 当上游供应商出现问题时，你是会提前发现还是等用户抱怨？
- 如何防止工程师破坏彼此的系统？
- 你是否有系统来确保团队协作顺畅，而不是把应用变成一团糟？
- 当出现重大问题时，即便你的工程师在睡觉，问题能否在我放弃之前得到解决？
- 你能从自身或上游的故障中恢复吗？重要数据会丢失吗？
- 你在持续跟进安全更新吗？会泄露我的数据吗？
- 我能信任你吗？我能依赖你吗？
- 你是否愿意签署一份具有法律约束力的保证，确保你的软件在我需要时一定能用？