技术“大跃进”进行中

2020 年 04 月 30 日 阅读数: 17
技术“大跃进”进行中

人类是贪心的动物,解决所有问题,都想要一个目标:多快好省。希望收益产出多,生产效率快、成品质量好,消耗成本省。在一个特定的问题域,找到一个多快好省的解决方案,便是通往成功之道。企业级软件的多快好省,除了功能性内容,还包括系统稳定性、软件性能、组织架构适配、合规性、安全(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. 当我们监控一个系统的时候,如果领导平时也不喜欢用电脑登陆系统,那么我们怎么汇报工作呢,一个是搞一个大屏幕,放到单位门口,领导进出们的时候就能看到,业务蹭蹭涨,故障处理效率极高,领导嘴上不说,心里美滋滋啊;但是领导看完又记不住,我们就每周、每月用报表的形式发送给领导邮件备份,领导想起来了可以看看,心里美滋滋,我们涨薪也就有希望了。

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

用户头像

冯夷

关注

技术型产品经理,知行合一,拖延症 2018.06.14 加入

悲观的英雄主义,热爱生活,希望能看清生活真相。

评论

发布
暂无评论
技术“大跃进”进行中