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

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

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

6.2.2 去掉中间环节

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

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

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

6.2.3 优化技术架构

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

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

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

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

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

7、新故事-维X

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

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

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

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

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

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

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

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

（编辑：源码门户网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!