服务治理目标
对于任何一个产品或者产品里面的某项功能来说，把东西开发出来只是一个开始，而这个产品或者功能被下线或者去除之前，都会有一个很长的维护期。
对于这个示意图，核心有两点关键：
- 开发阶段的成本是非常显性的，但是功能维护期，包括了功能迭代和售后维保，它的隐性成本往往更高。
- 产品的功能开发期虽然可能很短，但是它是起点，是源头。它每一分每一秒时间是怎么花的，很大程度上决定了这个产品或功能的最终维护代价。
以互联网为载体的软件，它不只是在功能上要满足用户需求，还要提供健康的24小时不间断服务。功能开发与维护的边界变得模糊，一些公司甚至每天都在发布新的版本。
而服务治理的核心目标，除了软件治理外，更重要的是考虑如何确保这些软件能够真正做到24小时不间断的服务。
服务治理系统
从服务治理角度来说，把软件做出来只是一个开始。接下来会需要涉及发布部署、升级、版本管理等等相关的话题。等软件在线上成功跑起来，为用户提供了服务，接着我们就要保证它不会挂掉，做到分布式高可用，对故障进行监控和告警等等。
服务治理并没有那么简单纯粹。虽然理想情况下我们应该尽可能自动化所有故障的恢复，但是故障的可能性太多，很多时候我们无法提前预知，这就意味着人工介入无可避免。所以，互联网不只是产生了服务端开发这样的工种，同时也产生了运维、业务SRE（Site Reliability Engineer网站可靠性工程师）这样的工种。
故障基本上是难以避免的。可能导致故障的因素非常多。大体可以分为这几类：
- 软硬件升级与各类配置变更。变更是故障的第一大问题源头，保证系统不出问题的最简单方法就是不去升级，但从用户的服务体验和竞争力来看，升级又是必需的。这就需要服务端开发与SRE之间进行平衡。
- 软硬件环境的故障引发服务异常。如：硬盘坏、内存坏、网卡坏、系统死机或重启，机房或机架故障如断网、断电等。
- 终端用户的请求引发的故障。如秒杀类，短时间内大量的用户涌入，导致系统承载能力超过规划，产生服务的过载。
工程师思维
保障服务健康运行，必然有大量的事务性工作，运维或SRE这样的职业也由此诞生。
如果我们停留在事务中不能出来，那么随着我们所服务的用户数量增加，必然需要招聘大量的人员来应对繁重的事务工作。如果我们花在工程项目上的时间太少，你的职业发展会变慢，甚至停滞。我们可以鼓励那些做脏活累活的人，但仅仅限于在这些工作不可避免、并有巨大的正面影响的时候才会这样做。没有人可以通过不停地做脏累活实现自己的职业发展。
那么，什么是工程师思维？
从浅层的意义来说，工程师就是要实现业务的自动化。Don't repeat yourself! 某件重复发生的事情只干一次就好，以后也不需要再重复做。所体现的内在逻辑就是如何把问题闭环，如何把问题彻底解决掉，而编码只是一种工具。
工程师这种把问题闭环，彻底解决掉的思维，看重的是自己工作内容的长期价值。如果我们只是在做事务，而并没有在实质性解决一个问题，那么这件事情的长期价值就是零。
所以本质上，工程师文化也是产品文化，把问题以一种自动化的方式解决。这才是我们真正应该尊崇的工程师文化。
从更深层次来说，工程师思维是一种系统化的思维。仅仅是编码和自动化是不够的，很可能你编码也只是在实现某种事务性工作，而不是用系统性或者结构化的方案来解决问题。
真正优秀的工程师会系统化地考虑方案的有效性。他们追求的是用最小化的编码工作来解决更大范围的问题。坚持自我批判的精神，相信过往的经验但是也不迷信惯例和权威，寻求本源，以数据为指导，从根源出发去系统性解决问题。