没有比“可视化”更好的一个词能概括运维的本质，而“可视化”又应该分成两部分：可视化的服务交付和可视化的服务度量!
第一部分：可视化的服务交付
早期的运维是从ITIL开始的，那个时候大家都不知道运维是什么，怎么做，幸好找到了一个IT服务最佳实践--ITIL。于是就开始了运维的摸索之路，从CMDB、服务台、事件管理、变更管理、可用性管理、容量管理等等逐步去了解，逐步建设自己的系统。但我们很快发现，这一完备的流程框架遇到了大规模运维的时候，就无法应对，或者说过多的聚焦于流程以及规范，我们发现很难提升运维敏捷度和精细性，并且我们还是不知道一个完整的IT服务边界在哪儿?如何实现它?
不过在ITIL的实践过程中，其实提出了一个很好的概念---IT服务。对于运维来说，提供一种高效、一致性、透明化的服务是运维的成功所在，这样就要求服务提供者屏蔽其提供的所有服务细节，因为对于服务消费者来说，很难对专业的运维服务内部细节掌握和了解。就拿服务器资源交付来说，从早期的研发要关心配置、OS初始化、自己安装系统、配置网络到最后交付到手里即插即用，服务的自动化程度和完整性越来越高。其实也是一种“架构及服务”的思想体现，把之前早期交付功能变成了交付服务的模式。
另外从运维事务或者活动的角度来说，如何对其进行一次或者多次的组合封装，把它们变成一个完整的IT运维服务，是此时的运维自动化重点方向。毕竟繁杂的运维事务不进一步封装，对个人或者团队来说，都意味着很高的学习成本和事务执行成本。在传统的IT运维组织中，我们能看到彼此事务之间的割裂非常明显，比如说网络、机房、服务器、应用部署等等，都是在不同的团队完成，彼此工作独立进行。在大一点的运维团队中，可能会有一个专门的运维研发团队来给这些日常活动进行自动化的封装和实现。在大规模海量运维中，必须要求有一个集成的平台来实现把这些事务流调度起来，否则无法提高事务执行的效率和质量。
对于如何封装这些事务或者活动，从DevOps中可以找到一些答案。DevOps提倡自动化一切，其中一条核心的主线就是持续交付。我把持续交付分成两类场景：一种是持续交付基础设施，一个是持续交付软件。当然持续集成更多的是偏重于后者。
持续交付基础设施是目前IAAS平台要解决的，利用软件定义计算、存储、网络等技术来实现对上层应用所需资源的快速交付。其中虚拟化技术是IAAS层持续交付的一个核心技术，虚拟化能够快速的创建资源，交付资源，回收资源等等，在早期也有人错误的认为虚拟化就是云计算。最新的轻量级虚拟化技术更是热点，根本的原因是把应用的交付在镜像级别交付了，从而进一步降低了应用交付的成本。
持续交付软件从代码产生的那一刻就开始进行管理，到编译、到测试、到灰度环境验收到正式环境部署，并且希望这条主线完全的自动化。具体的持续集成最佳实践如下【具体请参见--持续集成：软件质量改进和风险降低之道】：
面向程序包的持续集成非常简单，现在有很多的开源解决方案来实现，jenkins、go平台等等，但有一种情况需要非常注意，就是程序包的配置管理问题，这个也往往是影响发布的重要环节。所以我们很多时候使用开源平台只是让他产生程序包即可，后续的包的管理和配置管理以及后续的实例化发布，特别是大规模集群部署，都是由单独的发布平台来解决，而非持续集成工具(虽然它们也支持)。
基于软件的交付解决之后，这个时候我们一定会想，如何实现全应用的交付，此时便有了PAAS平台和基于应用架构的可视化部署服务两种方案。这两种实现思路有很大的不同，我们知道完整的PAAS平台是提供了对底层服务的统一抽象，比如说数据库服务、存储服务、cache服务，但是对于许多开发者来说，好像又不愿意收到这么多的约束，这也是PAAS平台一直没有火起来的原因。 PAAS平台最经典的实现应该是CloudFoudry了，国内很多PAAS平台基本上都是参考CF来实现。Cloud Foudry概念模型如下：
参照CF的基本架构，我们也有一个类似的PAAS平台实现(百度的PAAS平台也是如此)，示意图如下：
而在现实的情况中，很少有公司有能力把Mysql、MC、Fastdfs封装一个服务供上层应用调用。在这种情况下，可视化的应用交付就会演变成可视化的全应用架构部署。像完成一个业务流程图一样，完成全应用的部署，在这个时候，我们也自然想到的是IDE编程环境。首先把我们架构中各个服务抽象一个对象(类似delphi环境中的控件)，这些对象有相应的属性和状态，并且可以在线可视化编辑。把这些可视化的对象按照应用架构视图的模型构建出应用模板，点击模板进行实例化，此时翻译成各类的机器指令到相应的服务器上执行各类动作，这种实现便可以脱离某个服务的接口API约束。
综上所述，运维的自动化最终要实现可视化，IAAS和PAAS是可视化的一个高度体现。可视化是自动化的更高阶表现!
第二部分，可视化服务度量
在我的运维理念中，一直倡导数据驱动运维。有了数据，就有了事实判断的标准，就有了运维服务优化的方向。“除了上帝，一切人都必须用数据说话”，这是在运维工作中必须恪守的信条。在早期写过一篇完整的数据驱动运维文章【关于数据驱动运维的几点认识】。在文章里面体系化的介绍数据化运维的目的、数据的来源以及如何构建数据体系等等。
最近也在进行一个数据实践，就是建立端到端(立体化)数据分析体系，目标非常明确：*分钟发现问题，*分钟内定位问题。我们把数据建立一个标准化的分层体系，从基础设施、上层组件、到应用服务、到接口、再到用户侧，基于应用的拓扑架构，收集各类指标，统一到一个分析平台中展现。如图：
基于这套分层化的数据体系标准，当前我们也有对应的系统实现，具体如下：
当我们形成标准之后，这套标准化的方案可以向其他业务不断去复制，大家只需要遵循一套数据标准即可，最后数据的采集、分析、展现和告警都是标准化完成。
另外又针对单个用户访问情况，希望能实时的绘制它的业务访问流，开源的产品实现有twitter的zippkin和google的dapper。这类开源方案不能直接使用，只能借鉴其思想。当前我们就结合自身的业务架构特点，实现了一个统一的服务调度框架和名字服务中心，在业务代码无侵入的情况下，可以把业务调度链数据上报和整合，实现自己的业务访问流拓扑绘制。
运维的数据化能力非常重要，一方面也体现出你对运维的理解是什么样的，从数据上可以看到你很多运维经验的提炼;其次利用数据可以发挥运维的驱动能力，从某种意义上来说，数据不会说谎。最后，数据共享和可视化之后，大家有了一致性的理解，它所释放出来的能力非常大，无论是业务优化、服务改进都能从数据中找到方向。
因此我说可视化的能力代表了运维的能力，可视化的程度越高，运维的能力越高。那么你现在到底可视化了哪些运维服务，并能进行度量?
本文作者：佚名
来源：51CTO
