顺丰IT基础架构运维的焦虑与进化(3)

受限于人类只能串行的脑和手,工程师无论工作多熟练,其日常工作产出有限.2015年下半年正在开始,我们的基础架构团队开始系统性的对待运维自动化,经过近半年多的努力,我们已经可以做到用户提一个创建型需求,经过运维专业组的线上评估,点一个按钮,自动生成变更,在系统上设定一个时间执行该变更.非创建型日常变更更多是是半自动式实现,还处在路上的阶段.

运维日常工作中,沟通多半是邮件、IM?或者会议,时间都消耗在了沟通和等待中,其本质是一个信息传递和确认的过程.处理好信息的准确行和流通有效性,将工作流和信息流放在线上,通过系统可以有很大的效率提升,工单系统是一个典型的例子.

5.4 仍然焦虑

IT运营成本已经不是一个大问题了,服务交付的效率貌似也能够跟上节奏,是否可以停下来休息了?当然不行,互联网形态的系统一直在增加,其使用行为和用量的波动区间远超企业内部系统,对系统的健壮性和架构弹性提出了更高要求.“双11”峰值一年比一年高,如何更快、更有效的进行高峰应对,而不是靠人来堆?

更轻更快是一个扑面而来的要求,而当时的实际情况则让人焦虑不已.

• 一是流程重,以?ITIL?理念设计的流程更看重质量,效率不能很好的兼顾,人和事被流程牵着走；
• 二是自动化,把整个流程拉开来看,从需求的发生到结束,自动化只是替代了末端执行环节的手工作业而已；
• 三是架构弹性弱,高峰应对的扩容评估、压力测试、扩容执行周期长,是“人肉”祭场.
• 四是技术架构纵深层次多,部分重要数据要在?SAN?集中存储,数据存储单点如鯁在喉,是运维人心头上的一根刺,急待解决.

6、狂奔–重定义架构和专业

6.1 基础运维十字架

基础架构很多种工作,我们将其分为价值四象限.从外部来看,右上角为价值区间,即我们能够为业务单位、研发单位等上游部门提供怎样的科技能力助力公司战略目标的实现.

左下角完全是为了系统稳定而进行的日常运维工作,重复性非常高,而且只要不出问题,外界基本无感知.整体来判断,纵轴右面的工作价值高于左边,正常理解的话,运维团队的资源应该更多的投入到右边的工作中.

很可惜,实际情况正好相反,彼时运维团队75%时间在做各种琐事,25%做进阶工作而已.结果本应右手解决左手的问题,但是右手腾不出来,左手也一直在忙.

6.2 重新定义专业和能力

6.2.1 专业重定义

为了再一次蜕变,摆脱运维十字架的负重,我们决定重新定义专业能力.以往专业团队掌握技术软件,熟练进行各种应用场景和使用方法就够了.现在够不够?明显不够!

再一次,我们需要重新组织队伍：

• 一是技术团队不能只做日常工作,一定要沉下心做专业领域的研究；
• 二是运维团队上浮,日常基础架构运维团队聚焦应用,基础架构运维人很多时候根本不了解应用系统,也不关心主机、存储和网络上跑什么系统,每次出现问题处理的要求时,大家都各讲各话；
• 三是研发团队聚焦,聚焦在打通专业壁垒,做到更彻底的运维自动化.

6.2.2 去掉中间环节

在烟囱垂直专业分工模式下,一个系统颗粒度的完整作业,工作流需要类串行的流经所有的专业团队,中间沟通环节多,慢! 对用户而言,如果能够实现端到端的自助交付或自服务是最快的方式,要做到这一点,需要要做基础架构数据整合和可视,打通专业和安全壁垒.

另外在队伍的组织层面,在整个平台打通工作还未完成前,可以尝试全栈运维,联合作战,在组织层面降维,让大家在一个平面上工作,实现信息和能力的透明共享.

在互联网系统领域,我们把基础架构专业人士抽一部分出来,和应用运营同事放在一起组成完整能力团队.现在效果比较明显,专业都有了,相互影响和学习,整体工作能力和效率都有提升.

6.2.3 优化技术架构

传统架构层次较深,尤其是数据存储层,不但徒增交付工作环节,同事有事数据安全和性能的热点,怎么办?对数据库的用途进行轻量化处理.

数据库只作为数据存储容器,不要把太多逻辑放在数据库处理.应用层要承担更多逻辑的实现,同事对数据库进行分片来拉低数据库主机和存储的需求门槛,一个数据库承载的数据量太大,逻辑太重,对数据库所在主机提出更高的要求,才会出现以前很多企业用小型机或更好的机器和光纤存储.

当然,对于 MySQL 数据存储本地化后,数据库 HA 方案不管是数据的完整性和切换的效率方面都要做好严格的设计和验证,我们的 ThinkDB 就是为解决这个问题而起的任务,从当前的进展来看,是完全可以解决的问题.

在资源和架构的弹性部分,如何更弹性?大家在物理机集群遇到一个问题,扩容要有机房同事把机件上架、拉好、初装,一旦涉及物理设备的操作就会变慢和重,这时我们将物理设备准备工作前置池化,当然,在量方面做好预测工作.逻辑层使用 Docker?和?KVM?虚拟群来做到相对轻量化的快速横向扩展.

谈到这里,开源的好处进一步凸显,开源可以无缝支持可编程的基础架构,投入一些研发资源,除了物理设备本身外,很多逻辑层的工作都可以从手工搬到线上,定时定量都可以处理,而且相关运维标准植入系统后,标准化的工作可以执行的更好.迄今,这些设计已经进入我们的技术架构标准.

7、新故事-维X

虽然我们可以在管理、团队组织进行局部优化,但无法解决一个问题,当一个团队大的时候,当你管理的设备、应用形态、软件技术多了,如何做到所有的人都知道状况?

如何共享信息、流通信息,一旦信息无法共享和流通,所有人都站在知晓的信息范围内工作怎么办?

我们看了业内一系列的解决方案,也和业内同行交流了很多次.他们都是非常优秀的平台和软件,我们发现这件事最后还得自己来.

平台渗入了一定的管理思维,对公司的能力、组织形式、业务形态以及相关的管理理念都有要求,你接受一个软件必须接受那些东西,能否完全接受,接受后的调整和适应需要多长时间?最后评估的结果是还得自己干.

我们希望通过维X,做到基础资源的提供、专业能力的提供,都以原子服务的形式在满足安全的前提下暴露出来,在系统进行集成,让我们的被服务方能够自助的获取,给我们的上游团队赋能,达到价值最大化的效果.

这个平台应该有几个特征：一是数据共享透明；二是交付自主；三是专业服务能够自服务；四是自调整和自适应；

谈智能有点超前,我们短期做不到这种程度,但相信前四点能够解决我们大部分的问题.这条路不易,运维人员开始转型运维研发人员时,思维模式和对研发项目的组织是欠缺的,后面有一定的积累再和大家分享!

文章来自微信公众号：高效运维

（编辑：ASP站长网）