技术“大跃进”进行中

人类是贪心的动物，解决所有问题，都想要一个目标：多快好省。希望收益产出多，生产效率快、成品质量好，消耗成本省。在一个特定的问题域，找到一个多快好省的解决方案，便是通往成功之道。企业级软件的多快好省，除了功能性内容，还包括系统稳定性、软件性能、组织架构适配、合规性、安全（4A、安全通信、加密狗等）、支撑规模等方面，均需有一定保证。

作为产品人员，只有一个心愿，做一款真正有价值的产品。对有价值的理解是能够解决问题。产品人员首先要面对的，就是找到那个真正重要的、最核心的问题，借助团队的力量，将问题转变为算法，形成产品，并保证产品本身的可用性。而发现这个秘密，找到解决方案的往往不止一个团队，所以需要保证产品的差异性。

在业务支撑软件领域，我们希望用软件重新定义一切，让硬件变成计算模块、存储池、流量通道。而在整个支撑软件的发展过程中，有一些趋势的变化，从最早的标准化、流程化，到自动化（工具化、脚本化）、可视化，以及现在提倡的系统化、平台化，还有我们预期的智能化。这些内容都脱离不了三个核心要素：PPT（人（People）、流程（Process）、技术Teck/工具Tool），在整个发展过程中，人所占比重越来越小，流程逐渐内置到技术工具中，直至形成一个自治自洽的系统，实现DC的智能化。

在IT管理发展过程中，ITIL是一个不可不谈的内容，其形成了一个极为完整严谨的体系，将服务交付和服务支持作为两个核心点，引入了服务水平、财务管理、可用性管理、能力管理、持续性管理，引入了事故管理、问题管理、配置管理、变更管理、发布管理等协议及流程。而其中CMDB作为配置管理落地的关键，成为了ITIL必然建设的一环。ITSM和ITIL一般等同，基于CMDB和工单系统，完成各类流程的定义和维护。这个阶段，人的弱点被接受和认可，更强调流程的作用。而流程在一定程度上，又限制了组织效率。所以，在社区逐渐出现了其他声音，倡议弱化ITIL、简化ITSM建设，引入DevOps，提倡打破组织藩篱，学习精益制造流水线理念，将软件开发以单件流的模式开发，提高产出效率。而同时期，Google出现了一群SRE工程师，他们认为SRE是DevOps在Google的实践，目的都是为了简化流程，提升效率。当然，也有另外一种声音，认为所有开发（或者所谓的运维开发工程师）为运维人员做的系统根本用不起来，所以由运维人员切入开发环节，了解业务开发架构，自己开发运维相关系统，打通开发运维通道。CI/CD就是DevOps中最为典型、最有落地可能的模块。而SRE是Google那批本身具备开发能力的人，重新将管理数据中心的问题以程序思维重新设计。而这两种，都逼迫传统运维退出市场。

在理论发展的过程中，市场上的实践派也分别拿出了他们自己的解决方案，最早提倡ITOM（IT运营管理）、ITOA（IT运营分析），主要就是去打通IT资源的管理和监控分析，而其中关注于业务系统的人提倡ALM（应用生命周期管理）和APM（应用性能监控），以实现业务资源的管理和监控分析。不论是ITOM、ITOA还是ALM、APM都是以On-premise的方式交付给用户，但随着云计算大潮的来临，事情变得不同。云计算将计算、存储、网络包括上层的基础组件，以即时、按需的方式提供给二方使用，二方依赖云计算资源去完成业务系统的构建。IT运维服务则由云计算部门（私有云其实也算是本地部署，但是刻意将运营方和使用方分离了，所谓的将成本中心转为利润中心）完成，而在整个过程中，因为集中化更可控，所以云计算软件会将运维自动化提升到一个前所未有的高度，直至自治。

云计算按照Gartner的分法，只有IaaS、PaaS、SaaS：IaaS提供基础计算资源如虚拟机、分布式存储、VPC网络(一般包括DNS和LB)；PaaS提供分布式计算、调度框架，提供编程框架脚手架、提供各类基础支撑服务如消息队列、缓存、数据库；SaaS提供业务类服务如客服系统（网易七鱼）、CRM（纷享销客）。而因为云计算热度激增，又逐渐出现了LBaaS、DBaaS、BaaS等，以提供负载均衡服务，数据库服务，公共业务服务（如短信验证、社交化登录分享、搜索服务）等。而且因为不同业务负载对计算资源性能要求不同，也因为云计算厂商对计算资源切割粒度不同，出现了以baremetal（裸金属）、容器、Serverless为不同计算颗粒的服务类型。裸金属服务一般会归到IaaS，容器一般会作为新一代PaaS的核心，而FaaS则是serverless的典型服务场景。

服务支撑方式的变更，实际上是沿着开发模式的变更同步变奏的，开发从最原始的单体架构，到面向服务的开发模式SOA，到以springcloud、dubbo为核心开发架构、以rpc、restful为核心交互手段的微服务，再发展到目前的云原生应用，业务系统切割粒度越来越细。因为敏捷开发、重构技术的落地性越来越强；互联网对业务敏态的要求越来越高；以及互联网对传统稳态业务的冲击，都让开发朝着轻量级、独立部署、复杂编排的模式上演进。所以在目前形势下对支撑系统的要求比传统模式下更高，支撑系统只能借力于云计算模式，以复杂支撑系统，独立部署轻量级业务模块来支撑。

我们对基础架构的要求，是完全的自动化，并且支持多种模式。如存储需要支持块存储、对象存储、文件存储多种类型；网络必须是VPC可定制的模式，还需要提供全局DNS、LB方案；计算资源最少支持裸机（物理机）、虚拟机、容器。这一切都是因为目前软件交付方式（软件交付的变更也很复杂，这也是这么多包管理软件的原因，ELF可执行文件、zip、tar.gz压缩文件，bin包，rpm、yum，vm image、container image，包管理的概念多么深入人心看helm就知道了）的不确定性、对资源性能要求不同、可控力度不同导致，如果有朝一日容器/镜像标准一统天下，那交付镜像，运行容器即可。

如果我们提供以下的能力，是否就能认为自己拥有一个自动化的基础设施呢？支持复杂组件的编排、支持资源的平衡调度、支持容器或非容器组件的部署、支持业务上线、支持配置管理、支持故障管理、支持容量管理、支持大监控、内置关键服务、支持弹性可扩展、支持服务管理及治理。每一项都支持对标开源软件公共功能，比如服务治理，提供路由策略（黑名单、白名单）、限流、降级、容错、熔断等手段；比如故障管理需要支持故障隔离、故障告警、故障处理恢复手段。而内置的组件，以够用即可，因为在不同的系统中，有一部分功能是类似的（比如ESB中也会有服务安全，API网关里有，servicemesh里也有；比如代理软件可以选择nginx、apache，还可以去部署vanlish、squid，既可以部署haproxy也可以部署traefik，既可以部署jaeger，也可以部署其他trace，需要确认业务系统所需），在不同技术阶段也出现过本质功能类似但技术架构完全不同的组件（比如corba、webservice、esb、api网关、servicemesh））。

如此众多的功能和组件选择，会陷入盲人摸象的困局，如果摸到的只是大象鼻子，怎么可能做一个适合大象的产品呢？对问题域有一个系统化的认知之后，找到做哪一块，如何突围（要建设一个完整的系统，需要哪些环节来支撑呢？照着AWS做，肯定是对的，但是花多少钱才能做的和人家一样呢？所以突围的点必然在其他地方），对组件成熟度的考量，都会是一个问题。而如何与现实对接适配，比如适配组织文化和架构，以及当前的模式，包括技术模式，与现网一些系统的集成，都会更耗费心力。

目前大家都喜欢聊ABCD，AI、Cloud这个确定占了AC，B是BigData还是BlockChain说法不一，D是Data还是DevOps也说法不一。所以立足于Cloud，引入AI、大数据技术分析运维数据，解决DevOps问题，一种占尽风流的既视感。但实际落地的时候，功能名称是如此单调，监控、调度、管理，是频繁被使用的几个词，加上不同前缀形成新功能，比如：分布式监控、调度、管理；容器监控、调度、管理。最早的数据仓库、数据湖、BI，名字都起得不错，可惜过气了。故名字不是关键，解决问题的能力才是关键。系统发展到如今，复杂的环境里，单纯一个对一个软件的运转已经不能满足要求，就拿DNS来说，Google的DNS已经是一个庞然大物，而非简单的IP换域名。弹性伸缩，这种大家都在聊，而实际没多少用起来的功能，在细节细化上也存在众多问题，是否支持集群弹性伸缩（ClusterAutoScale）、是否支持组件弹性伸缩（HPA）、是否支持专用弹性伸缩（nanny、dns-autoscale），并且如何与IaaS的弹性伸缩服务集成，如何避免震荡，如何避免资源耗尽，如何端到端开通服务通道，都是头疼的问题。传统的配置管理软件如Ansible、Puppet也会在新环境下变得无力适从。所以，我的理解，一个自动化、自治的生态不是单纯的功能叠加，需要在一个成长环境，物竞天择之后的产物。

以下以监控为例，单纯看看在云原生的系统里，大监控产品需要集成哪些能力:

1. 监控产品可分为主动监控和被动监控，主动监控以zabbix（snmp、sigar）、pinpoint（字节码嵌入）为代表，被动监控以httpchecker为代表，旁路监听也是一种方式。

2. 日志采集、存储、分析形成日志系统，也可以放到监控的范畴下去看，而通过日志埋点，也可以做到Trace系统，当然，也有其他途径来完成Trace的跟踪记录。

3. 监控信息一般通过两种渠道为人所识别，一种是基于层级化拓扑的可视化展现，一种是告警信息。关于监控信息的可视化展现，需要考虑人和机器的差别。人对事物的认知本来就分层次，有的人理解深入，故关心细节，有的人只关心概况，所以需要有一个分层的图来分级别展示信息，针对不同的监控对象，每个监控对象身上，是自己的监控指标、日志、埋点汇报等信息，而在大图景下，需要知道监控对象之间的关系，Trace更多时候用来做业务流程的描述，而业务流程一定程度和数据流是一致的，但除了这种真实的流向展示，其实还希望有一个从管理维度的关系展示。

4. 监控信息入库之后，可以通过告警策略引擎，根据预制告警策略（简单策略如10分钟内平均CPU大于90%的机器告警），根据告警策略关联监视对象维护人信息，生成具体告警消息，通过告警渠道发送给不同责任人。至于因为系统震荡，导致重复告警如何合并，避免告警风暴，那就是优化的事情了。

5. 当我们监控一个系统的时候，如果领导平时也不喜欢用电脑登陆系统，那么我们怎么汇报工作呢，一个是搞一个大屏幕，放到单位门口，领导进出们的时候就能看到，业务蹭蹭涨，故障处理效率极高，领导嘴上不说，心里美滋滋啊；但是领导看完又记不住，我们就每周、每月用报表的形式发送给领导邮件备份，领导想起来了可以看看，心里美滋滋，我们涨薪也就有希望了。

一个基础设施服务提供商的产品终极目标，便是提供除了业务系统以外所有能力，并且能以低于用户自建的成本提供，提供高于用户预期服务质量保障。希望能够做到真正给用户带来价值的好产品。