-
-
瑞艾 数据达人Lv4
发表于2018-12-19 17:53
楼主
没有比“可视化”更好的一个词能概括运维的本质，而“可视化”又应该分成两部分：可视化的服务交付和可视化的服务度量!
早期的运维是从 ITIL 开始的，那个时候大家都不知道运维是什么，幸好找到了一个IT服务最佳实践——ITIL。开始了互联网运维的摸索之路，从CMDB、服务台、事件管理、变更管理、可用性管理、容量管理等逐步去了解，并同步建设对应的管理平台。
但我们很快发现，这一完备的流程框架如果遇到了大规模运维的情况，就无法应对，原因在于过多的聚焦于流程以及规范，我们发现很难提升运维敏捷度和精细性，并且我们还是不知道一个完整的IT服务边界在哪儿?如何实现它?
不过在ITIL的实践过程中，其实提出了一个很好的概念——IT服务。对于运维来说，提供一种高效、一致性、透明化、面向用户的服务是运维的价值所在，这样就要求运维屏蔽其提供的服务背后的所有实现细节。
从运维具体事务或者活动的角度来说，如何对其进行一次或者多次的组合封装，把它们变成一个完整的IT运维服务，是此时的运维自动化重点方向。毕竟繁杂的运维事务不进一步封装，对个人或者团队来说，都意味着很高的学习成本和事务执行成本。
在传统的 IT 运维组织中，我们能看到彼此事务之间的割裂非常明显，比如说网络、机房、服务器、应用部署等，都是在不同的团队完成，彼此工作独立进行。在敏捷和精益运维驱动之下，必须要求有一个集成平台来把这些事务流调度起来，否则无法提高事务执行的效率和质量，真正地把运维交付功能变成了交付服务的模式。
对于如何封装这些事务或者活动，从 DevOps 提倡的“自动化一切” (Auto everything)可以找到些答案，其核心的自动化主线就是面向用户的敏捷持续交付。我把持续交付又分成两类场景：
一种是持续交付基础设施，一个是持续应用交付(持续构建、持续测试、持续部署、持续反馈)，他们有点近似IAAS和PAAS的关系。
持续交付基础设施在公有云 IAAS 平台中得到很好的解决，利用软件定义计算、存储、网络等技术来实现对上层应用所需资源的快速交付。
在私有IT环境中，当前有大量客户采用虚拟机方案或者私有云方案来解决交付难和慢的问题。最新的轻量级虚拟化技术Docker更是热点，根本的原因是把应用的交付在镜像级别完成，从而让应用交付更加快速。
持续交付软件从代码产生的那一刻就开始进行管理，到编译、到测试、到灰度环境验收再到正式环境部署，并且希望这条主线完全自动化。面向程序包的持续集成非常简单，现在有很多的开源解决方案来实现，如Jenkins、Go等，但有一种情况需要特别注意，就是程序包的配置管理问题，这个也往往是影响部署的重要因素。所以我们很多时候使用开源平台只是为了构建程序包，后续包及其其中的配置管理以及实例化部署，特别是大规模集群部署，都是由单独的持续部署平台来解决，而非之前的持续集成工具(虽然它们也支持发布)，但持续部署平台需要有和持续集成平台无缝对接的能力。
基于软件包的交付解决之后，我们希望交付的粒度更大，如何实现全应用(从应用的前端接入到后端存储)的交付，此时便有了PAAS平台和基于应用架构的可视化部署服务两种方案。这两种实现思路有很大的不同，我们知道完整的PAAS平台提供了对底层公共服务的向上API统一抽象，比如说数据库服务、存储服务、Cache服务。PAAS平台最经典的实现应该是Cloud Foudry了，国内很多PAAS平台基本上都是参考CF来实现的。阿里UC也有一个类似的PAAS平台，示意图如下。
而在现实的情况中，很少公司有能力把Mysql、MC、Fastdfs封装公共服务供上层应用直接调用，意味着对研发程序有着一定的要求，是否还有一种更轻量的无约束自动化方式呢?我们可以把运维的全应用部署转变下思路，此时把应用架构中的各个部分拆解成对象组件(包含属性和状态)，比如说机房、OS、应用包等，全应用部署就是这些对象的编排，类似可视化IDE编程环境。
综上所述，运维的自动化最终要实现可视化，复杂的运维工作流必须通过可视化来表达，可视化后的自动化才能让所有人理解一致、执行一致、结果一致。
