没有比“可视化”更好的词来概括运维的本质，而“可视化”应该分为两个部分：可视化的服务交付和可视化的服务测量！***部分：可视化服务交付早期运维从ITIL开始。那时候大家都不知道什么是运维。幸运的是，我们找到了一个IT服务最佳实践——ITIL。开始了互联网运维的探索，从CMDB、服务台、事件管理、变更管理、可用性管理、容量管理等逐步了解，并同步搭建相应的管理平台。但是，我们很快发现，这个完整的流程框架无法应对大规模的运维。原因是过于关注流程和规范，难以提升运维的敏捷性和精细化。而我们还不知道一个完整的IT服务边界在哪里？如何实现？但是，在ITIL的实践中，一个非常好的概念——IT服务其实已经被提出来了。对于运维而言，提供高效、一致、透明、面向用户的服务是运维的价值所在，这就要求运维屏蔽其提供的服务背后的所有实现细节。从运维的具体操作或活动来看，如何将它们进行一次或多次组合、打包，成为一个完整的IT运维服务，是此时运维自动化的重点方向。毕竟，复杂的运维任务如果不进一步封装，对个人或团队来说意味着高昂的学习成本和交易执行成本。在传统的IT运维组织中，我们可以看到彼此的事务之间的分离是非常明显的。比如网络、机房、服务器、应用部署等都是由不同的团队完成，相互独立工作。在敏捷和精益运维的驱动下，必须需要一个集成的平台来调度这些交易流，否则交易执行的效率和质量无法提升，运维交付功能真正成为了一种服务交付模式。至于如何封装这些事务或活动，从DevOps所倡导的“Autoeverything”（汽车一切）中可以找到一些答案。核心自动化线是面向用户的敏捷持续交付。我把持续交付分为两种场景：一种是持续交付基础设施，一种是持续应用交付（持续构建、持续测试、持续部署、持续反馈）。它们有点类似于IAAS和PAAS之间的关系。持续交付基础设施在公有云IAAS平台得到很好的解决，利用软件定义的计算、存储、网络等技术，实现上层应用所需资源的快速交付。在私有IT环境中，目前大量客户使用虚拟机方案或私有云方案来解决交付难、交付慢的问题。最新的轻量级虚拟化技术Docker更受欢迎。根本原因是应用交付是在镜像层面完成的，这样应用交付速度更快。持续交付软件从代码生成开始，到编译，到测试，到灰度环境验收，再到正式环境部署，都在进行管理，希望这条主线实现全自动化。面向包的持续集成很简单，现在有很多开源的解决方案，比如Jenkins、Go等，但是有一种情况需要特别注意，就是包的配置管理，这往往是影响部署的重要因素。因此，我们经常使用开源平台只是为了构建程序包。后续的包及其配置管理和实例部署，尤其是大规模集群部署，都是通过单独的持续部署平台来解决，而不是之前的持续集成。工具（尽管它们也支持发布），持续部署平台需要具备与持续集成平台无缝对接的能力。解决了基于软件包的交付之后，我们希望交付的粒度更大。如何实现整个应用的交付（从应用的前端访问到后端存储）。这时候就会有PaaS平台和基于应用架构的可视化部署服务。有两种选择。这两种实现思路是非常不同的。我们知道，完整的PaaS平台提供了一个向上的API对底层公共服务的统一抽象，比如数据库服务、存储服务、缓存服务等。PaaS平台最经典的实现应该是CloudFoudry。国内很多PaaS平台基本都是参照CF实现的。阿里UC也有类似的PaaS平台，原理图如下。现实中很少有公司有能力将公共服务封装在Mysql、MC、Fastdfs中，供上层应用直接调用，这意味着对研发程序有一定的要求。有没有更轻量、不受约束的自动化方法？?我们可以换一种思维方式来考虑全应用部署运维。这时候我们可以把应用架构的各个部分拆解成对象组件（包括属性和状态），比如机房、OS、应用包等，完整的应用部署就是这些对象的排列，类似于可视化IDE编程环境。综上所述，运维的自动化最终还是要可视化。复杂的运维工作流程，必须通过可视化的方式来表达。只有可视化之后，自动化才能被大家所理解，执行上一致，结果上一致。第二部分，可视化服务度量“除了上帝，每个人都必须用数据说话”，这是运维人员必须遵守的信条。我写过一篇完整的数据驱动运维文章《数据驱动运维的几点认识》，系统地介绍了数据驱动运维的目的、数据来源、如何搭建数据体系，等等。最近也在进行一个数据实践，就是建立一个面向应用的端到端的数据分析体系。系统对数据进行了标准化的层级分类，从基础设施、上层组件，到应用服务、到接口、到用户。侧面，根据应用的拓扑结构，收集各种指标，展示在一个分析平台上，如下图。基于这个分层的数据系统标准，我们也有相应的系统实现，如下图所示。形成标准的数据采集、分析、展示系统后，可以继续复制该方案到其他应用。您只需要遵循一套数据标准。***数据采集、分析、显示、报警均标准化完成。这套数据系统搭建完成后，可以在运维故障定位、服务优化、架构改进、运维规划等各个方面找到应用场景。这时候，可能有人会疑惑，如何将这些数据整合关联起来，供应用使用呢？我们目前正在集成基于配置文件的静态视图和基于接口调用生成的动态视图。动态调用视图的生成有点复杂。名称服务中心可以接管所有在线接口调用的调度，对接口调用进行采样，生成动态访问关系。上述视图可以快速发现和定位大规模故障，但对单个用户的故障指标处理能力较弱。这个时候，分布式跟踪服务的作用就体现出来了。可以借鉴Twitter的Zippkin和Google的Dapper的实现思路。目前，我们已经根据自己的业务架构特点，实现了统一的服务调度框架和名称服务中心。在没有业务代码入侵的情况下，我们可以将业务调度链的染色数据进行上报关联，实现单一问题的快速响应。位置。数据可视化能力非常重要，既要针对整体，又要针对某个业务流程来实现。它首先体现了您对运维的理解，您可以从可视化的Dashboard看到最直接的运维体验；其次，基于可视化的数据共享，让大家对数据的理解达成共识；***用一致、可视化的数据，发挥运维驱动能力，驱动DevOps。这就是数据的核心价值。因此，可视化能力代表运维能力。可视化程度越高，运维能力就越高。那么你对哪些运维服务进行了可视化和实测呢？
