国内IT运维存在的痛点
伴随着IT在企业中的作用日益明显，IT建设和IT运维同时成为了企业效率的加速器。同时，计算机硬件系统和软件系统的运维已成为了各行各业单位，尤其是大型综合服务系统普遍头痛的事情。
运维之痛1：人工 vs 平台
人工不是传统运维的当下过失，是过去的延续。在早期，运维的很多能力建立在少量的高可用硬件对象之上，平台化的需求很弱。另外，闭源的软件生态，给平台化的建设增加难度，而这些历史债务，并不是一下就能丢下的。留给传统企业的时间并不是那么充足，开放平台和业务的互联网化带来的冲击是非常大的，时间非常的短。这是一个多维冲击能力，从思维、技术、能力等多个维度。
不过很开心的是，传统企业运维人对运维监控平台拥抱非常强烈，从运维自身能力自动化到全流程的持续交付自动化。我也经过和传统企业的IT部门深入广泛接触，大家对运维自动化作为突破口非常认可，更愿意以此为原点，单点突破，再全面覆盖。
运维之痛2：流程 vs 创新
很多人会告诉我，在传统企业中没办法，我们必须通过流程来驱动各个组织角色，确保协同工作。真的如此么？那么在腾讯维护那么多产品线，没有流程怎么做到的？然后真的会混乱不堪么？我和我之前的运维团队来说，如果你不能保持一个对外的简单清晰运维界面，那就是我们工作的失职。流程是我们找不到解决方案的时候，添加的累赘！而现在各式各样的一体化的运维监控平台正式扮演了这样一个监控流程的角色，维持监控的有序进行。
运维之痛3：责任分离 vs 持续改进
没有比责任分离更糟糕的事情了。在一个问题产生的时候，大家首先不是想着如何寻求更好的解决方案，而是在找这个问题应该由哪个团队的责任，责任分离。可以说是过度流程化的结果，流程设计者们很多都在精心设计责任应该由谁来背。当责任被清晰的界定之后，而后的解决方案也只能落到该团队上了，自然而然，思维就局限了。
其实应该换个视角，当业务的质量出问题了，持续交付这个链条上的所有人都有责任，而基于责任的分析范围应该更广泛一些，需要思维上的突破。我们总是怪测试不够充分，你给到足够的时间给测试了么？你让测试早期参与了么？你建立了稳定的技术框架，让自动化测试更好的覆盖了么？怪运维的环境部署有问题，你有降低运维部署的复杂度么？怪运维定位问题慢，你有把运维定位故障的复杂度降低么，消除了菜鸟和专家的区别么？反之亦然~ 系统的IT运维监控平台更好的把出现在问题降低到最少，相应的责任也会分担的最少。改进责任分离与持续改进之间的矛盾问题。
运维之痛4：组织设计
"设计系统的组织，最终产生的设计等同于组织之内、之间的沟通结构。
不得不说，传统的职能式的IT组织架构越来越不能满足互联网化的业务需要了。基于持续交付打造的全链条整合链条打破的就是职能边界，提供的就是面向产品化的服务能力。如果组织不能给新产品上线和老产品快速迭代提供足够的能力支撑，那么这个组织一定是冗余设计的。架构组提供的架构能力只能是一个意向参考，没有真正的落地实现，这个架构组就是冗余的；流程组提供的流程能力是减慢了交付速度，这个流程组就应该去思考是否把流程让位于更优的技术实现。
很容易观察到的一个效果，复杂的组织设计，最终让设计出来的软件复杂，导致问题重重，随后便不断的增加附加角色，让软件的交付过程主次不分。其实附 加角色增加的检查点并不能起到服务改善的作用，“越早发现缺陷，越早修复成本越低”这个准则需要深刻体会，check机制都是事后的机制，是人肉机制，而 自动化的机制必须早期介入。
糟糕的情况，组织设计完全面向问题，而非面向用户。谁能代替用户来对IT组织的考核？没有。但我们的方式恰恰相反，认为考核组就可以，针对每个小组，设计了一些指标。说实话考核组离一线现场太远了，数据的是非判断准则都很难建立。
运维之痛5：架构设计
架构设计的问题是一直是核心的技术问题所在。架构设计问题体现在很多方面：
1、不能建立统一的架构标准
架构师在传统企业中是普遍的存在，而架构规范恰恰不是普遍的存在。很多时候都让位于业务的复杂需求，认为技术架构标准可以放低。技术架构标准绝不是架构师的呼声，应该是产品线的统一技术要求。合理的技术架构，会大大提升后续的产品推出速度和演进速度。
2、从代码依赖到二进制依赖到服务依赖
很多传统企业的大型软件之间采用的还是代码依赖，当一个组件发生变化的时候，这个时候需要整个系统的全量更新。久而久之，更新的代码影响哪些外部系统，都不知道。这是深度耦合，给后续的测试和运维都带来了很大的难度。到服务依赖，才能真正的实现架构自治。
3、没有统一的开发框架
开发框架其实是统一技术标准的最佳手段，是真正的把架构规范落到了可执行层面。传统企业的架构组应该在这个点上多思考，统一的开发框架到底包含哪些？
4、业务需求优先，非功能性需求次之
要命的是，评估一个研发团队的绩效是从实现业务的功能需求角度去考核的。
