追求极致的IT性能运维，就是高度的精益运维！也是很多运维机构的难点。有的运维组织用稳定性/可用性/质量指标，有的团队用效率，有的团队用成本指标，等等。老实说，在以上指标中，我个人认为能够带来巨大变革和牵引力的是效率，或者说绩效，就是做一件事情的速度有多快。但很多时候，需要对这个IT性能形成一个准确的认识，才能形成真正的力量。 可能有人会说，为什么运维的核心目标不是追求业务的稳定性/可用性/质量呢？我个人一直坚持的观点是，这些指标根本不是运维人员的核心职责，而是开发、测试和运维共同的核心职责。记得JezHumble说过，“测试人员不能提高产品的质量，只能让质量透明化，更直接的说，测试是为了确认软件是否可部署”。而德明在谈及质量管理时直接说，“停止事后检验，实现高质量的依赖，从产品开始就开始思考质量。”其实我们的运维流程类比也是一样的。软件不能靠后期的运维来实现高质量的业务，而应该把运维作为早期软件设计过程的一部分。 我们讲的是对IT性能的追求，这也是早期一个管理思想——精益思想的来源。精益思想五项原则所包含的内核是“拒绝浪费，创造价值”。从一开始就要求从客户的角度来定义产品价值（满足某些功能或服务的需求）。通过对这个价值的定义，进而逆向推导内部价值活动流程，如需求设计、总体设计、详细设计、软件开发、测试、运维等。拉动价值创造过程是一种价值创造，让客户的价值需求来决定内部活动。这是一种精益方法和有目的的行为。持续改进至完美状态。实际上，从传统的软件开发瀑布模型到敏捷模型，再到DevOps模型，这个过程的目的是为了让软件创建的多个功能组很好地衔接起来，而不是停滞不前。这里需要提到的是持续集成，它是实现精益的有效手段，也是最好的实施方式。在这个理念的背后，无一不是对性能和品质的极致要求。比如在精益思想的理解下，等待是一种性能浪费。 从软件交付的角度来说，运维是最贴近用户的，所以运维的IT绩效与整个IT组织的绩效息息相关。它的持续改进。IT性能的核心识别原则是从用户的角度来设置指标。其实本质上，IT性能的核心指标是吞吐量和时延，但这两个指标需要进一步与用户价值流去关联。进一步分解，可以形成如下指标体系： (1)服务交付的延迟 延迟是看完成一次服务交付需要多长时间。这个地方有很多场景，最核心的是两类场景： 第一，软件新功能新特性的持续交付过程，应用发布的过程，处理的粒度是应用，就是与开发测试过程密切相关。这就是目前持续集成思想的范畴。 其次，由于容量、服务搬迁等原因，面向用户的整体服务的交付过程，如用户访问量增加、数据库扩容、前端扩容、扩容某个组件的等等，这个主要关注运维的内部流程而已，不需要软件设计，软件开发流程接入，纯运维输出。以下是一个完整的服务上线流程图： (2)服务投放频率 频率可以看成是单位周期内的投放能力。一个典型的场景是每月持续部署的数量，从中可以计算出交付频率。下面是我们目前游戏持续部署平台的交付能力。有了平台，对人的依赖性大大降低，吞吐率大大提高。 刚才提到的整体服务交付流程，可以通过自己的业务调度变更平台输出。这个地方侧重于批量操作的能力。例如，一个变更单可以扩展多少个单元，需要多少时间？这往往是用户在需求的驱使下，所以对他的巡检频率要求不是太高。 （3）故障恢复的延迟 故障恢复的延迟将直接影响服务的可用性，影响用户对产品质量的感知。服务恢复越快，运维故障处理能力越强。在进一步细分故障处理能力的过程中，可以分解为故障发现、故障定位、故障处理和解决三部分。这三部分直接考察运维能力，这三部分能力可以直接映射到监控系统。故障发现需要监控系统向基于用户的实时监控方向发展；故障定位需要监控系统具备打通基于用户流量的数据能力；故障处理需要运维人工处理经验的沉淀，然后自动化。 有了以上的核心指标，我们需要同时思考那些会影响IT性能的因素，而这些点需要后续持续改进。我个人也总结了一些自己看到的几点： (4)建立开发和运维之间的互信运维的价值。只有运维才能站在所有业务的角度，搭建一个统一的IT服务平台，供业务使用。对于公司来说，这也是减少浪费的一种方式。开发和运维之间相互信任、合作、责任分担的团队氛围是一个高绩效运维团队的基础。没有研发测试的支持，运维只能做底层的服务封装，缺乏对运维的支持。深刻的理解。 （5）团队的多样性 对于运维团队来说，首先要保证运维研发和运维执行者的角色匹配，但是需要有一种机制，运维执行者需要不断的改变需求给运维研发团队，让他提供平台实现，甚至运维执行者自己也需要去尝试改变，让他们有运维的能力维护研究与开发。其次，对于团队来说，需要循序渐进。运维执行不行，运维研发不行，所有运维技术专家不行。需要具备较强的驱动能力、较强的技术能力和运维匹配能力以及较强的研发能力等；最后，运维团队需要有女性角色。当然，你不能把她当男人来用，这样你的团队就会缺乏灵活性。 （6）可视化运维流程 我觉得没有比可视化更能驱动运维流程的运维流程了。但是当你想到可视化的时候，你必须想着如何简化你的运维过程，否则实现起来会很繁琐。可视化是运维把问题简单化，让思路由模糊变清晰，把工具变成产品的过程。 （七）持续交付（持续集成+持续部署） 这是敏捷业务形态的标准配置，也是互联网业务的标准配置。但是，对于传统业务来说，持续交付似乎很难实现，其中很大一部分与服务耦合有关。不知道Jenkins不可能做互联网，不知道持续部署是不可能的。具体的最佳实践可以参考【持续集成】一书，里面有很多最佳实践标准。 （8）一键调度平台 利用该平台解决整体服务交付能力问题。服务被抽象为API以供调用。这时候就需要对线上服务环境做一些标准化的约束，比如把服务之间的调用抽象到名称服务中心，应用环境对系统环境零依赖。线上技术架构的运维管理应该是API服务化的，可以通过API来控制技术架构中的服务，比如配置文件管理/组件服务管理/服务降级服务/服务过载保护设置，ETC。越是API化，对机器的掌控能力越强，也就意味着运维性能能力越高。 （9）端到端的监控平台 监控对故障恢复的延迟起着核心作用，需要变运维的被动监控为主动监控。实现站在用户的角度主动监控，是真正的监控系统发现问题的有效手段，而不是传统监控系统从系统内部指标看问题。端到端，从用户端到服务端，根据应用的拓扑结构完成整个数据路径的构建。 还有一个因素需要特别注意，就是架构的智能决策能力。我个人在推广SDK双中心的时候，当我们将服务故障恢复时间设置为8分钟时，发现真正的系统恢复能力不靠人，而是让后台故障被前台感知，所以前台可以实现智能决策，屏蔽故障节点。这样的例子比比皆是。mysql故障被proxy屏蔽；代理故障由名称服务调度和屏蔽；名称服务故障高可用，不依赖中心节点；逻辑层故障也由名称服务中心进行调度和屏蔽；Web层故障通过负载均衡层调度屏蔽；负载均衡层故障通过DNS或httpdns调度屏蔽。 IT性能应该成为运维团队的核心驱动力，它能直接反映运维能力的高低。运维对IT性能的极致要求，也直接体现了运维团队的自我价值要求，甚至决定了运维团队的能力建设。没有IT性能最强的运维团队，只有IT性能更强的运维团队。就像优化在线业务程序一样，运维团队的性能优化永远不会结束。
