背景
最近一段时间由于工作内容重心变化，从PaaS系统的设计到运维系统的设计。运维系统的设计对我来说，还是一项全新的领域，需要学习的理念与技术很多。全司虽有大量的产品涉及到软件系统，但本质还是一个硬件盒子，运维的对象还是偏硬件。
熟悉电信IT系统的人或许听说过：OSS(Operation Support System)，运营支撑系统，它是运营商IT系统中三大支柱系统之一。其它两大系统是：BSS(Bussiness Support System), MSS(Management Support System)。
OSS是面向资源的后台支撑系统。资源主要包括网络，电信设备，计算系统等。系统的主要功能是包括专业网络管理，综合网络管理，资源管理，业务开通，服务保障等。但公司的产品线众多，产品形态也是千差万别，公司的OSS产品也一直在探索与发展。产品开发部门也是分分合合，一直是想打造一套统一的运营支撑平台。
我们所说的OSS，其实与互联网的业务运维系统主要功能也是相同的：
- 对网络，设备，计算系统，业务系统的监控，维护
- 对监控数据的智能分析，结果用于支持业务运营决策
而我现在工作的范畴也是面向软件业务的运维系统构建，与一些业界（互联网公司）的同行交流，发现运维理念是在面向的业务特征与场景上有着显著的差异。总结起来是业务产品形态决定运维系统的模式, 大概分为两种运维模式：
标准化运维
标准化运维是基于标准化的体系建设，对业务环境、配置、操作、流程等通过制定、发布和实施标准达到统一，以获得最佳秩序和效益。标准化的优势是显而易见的，标准是实现运维自动化地基础，是提高团队效率的重要方式，是梳理运维杂乱问题的重要依据。
标准化运维模式是非常适合于自研业务的运维。自研的业务在行政政策下，标准规范可以统一规划，推广普及。所有的业务在服务器、操作系统、中间件，语言框架统一选型；制定统一的业务开发规范，如安装目录，配置标准，日志标准，发布包标准，CI/CD流程标准等。标准化制定由统一的委员会制定，委员会由各领域的专家组成，规范基于业界或自身一些最佳实践整理。
标准化的另一个目的是可以简化运维平台的建设，让人和系统更有效率地做事。尤其是在一个大型企业，若先不做规范，就做运维系统的建设，到最后极可能会失控，运维系统变得自已不可维护，整体成本倍增。符合标准规范的业务，可以快速接入到运维系统，操作流程化，自动化，从而提升运维效率，减少维护成本的支出。
标准化不只是针对有问题的地方，就去设定规范和标准化，输出相应的规范文档。而是把规范工具化，规范必须沉淀到平台，才能真正做到方便运维，体现规范的价值。
我司在标准化做得非常的好，设计了一个专门的行管组织，制定了相当多的标准规范。但随着时间的推移、人员的更替、业务的发展与技术的换代，标准化也可能变成了教条。标准规范只在一定时间，一定范围内才能最大效益化。另外一个需要注意的问题是，若行管组织只负责规范制定，不对具体的业务运维负责，也会导致规范会越来越脱离实际。
SaaS运维
另一种运维模式是运维能力平台化，把运维能力通过API的方式开放出来。不同的业务运维基于API开发、模板定制、能力编排来开发与定制SaaS运维应用。SaaS运维的基础是运维系统的能力成熟度与开放度。
SaaS运维模式非常适合于异构环境下的业务运维。尤其是业务系统非公司自研，购买于不同的厂商。这是因为他们的资源诉求不同，架构不同，运行形态不同，操作流程不同。在这种场景下，标准化运维很难执行落地，业务购买时已成型，不可能再修改；采购时也不太可能要求供应商遵循你私有的标准。
随着云计算的发展，现在越来越多的传统APM（Application Performance Management）或其它运维产品的公司推出他们的运维SaaS在线云服务，业务系统可以接入到运维系统或使用其提供运维云服务，来完成业务的运维，从来减少运维的基础设施投资。
SaaS运维是一种新的模型，也是后续运维系统的主要发展模式，SaaS将是未来主战场。但SaaS运维系统构建的困难相对于标准化在于：
- 无侵入的运维接入
- 集成与被集成能力
- 简易定制开发能力
- 运维数据的安全性
- 运维生态系统构建
小结
标准化运维与SaaS运维有着不同的适应场景，但他们并不完全冲突，在SaaS运维系统中，也可以引入一些标准规范。目前一些开源社区或基金组织在推动一些项目，如OpenTracing，Prometheus Exporter等，这可能会形成事实标准。在云时代，SaaS云运维刚刚起步，也将是群雄逐鹿，有着不少的机会。