救火运维逆袭攻略:云原生+ DevOps+ SRE+ ITIL

云计算 云原生
可观测能力是当前热门的方向,包括指标监控、追踪和日志记录。我们可以从用户视角出发,关注稳定性、性能和产品易用性。在市场上有很多成熟的产品可供选择,通过外部合作(购买)的方式快速具备可观测能力。

前言

本次分享将从以下几个关键点展开论述:

时代:了解时代的趋势和大方向,才能事半功倍。雷军有个著名的理论——“飞猪理论”,即站在风口上,猪都能飞起来,这也表达了把握时代趋势的重要性。

加速:在把握时代趋势的基础上,选择关键技术要素,加速运维技术保障体系的建设。同时,需要考虑公司的现状特点,避免脱离现状构建“空中楼阁”。

技术:云原生时代的关键技术是我们深入探讨的重点。然而,技术不是我们的目标,解决业务问题、业务痛点并带来业务价值才是我们的目标。因此,我们应该开放连接,避免重复造轮子,借助云原生时代的IaaS、PaaS和SaaS能力,加速我们的能力成长。

图片

趣丸科技成立于2014年,是一家集兴趣社交及电子竞技等业务于一体的创新型科技企业。公司积极布局多元化赛道,紧跟Z世代心智发展,最大化创造用户价值。作为国内领先的兴趣社交平台,TT语音是我们的拳头产品,累计注册用户已超1亿,并成为LPL、KPL、PEL等六大头部电竞职业赛事官方合作伙伴。

以下内容是基于我们公司的现状经验,不一定全部适用于其他公司和场景,如果有其他问题,欢迎大家一起交流。

一、运维趋势和挑战

提到趋势,有一个词让我印象深刻:VUCA。

VUCA这个词最早是在90年代冷战时期提出的,当时世界变得不确定和复杂。回顾我们过去三年的变化,我们也能深刻感受到VUCA的意义。

图片

面对VUCA时代,需要找到应对措施。我们可以从两个角度来看待这个问题:一是“黑天鹅”,指的是发生概率较小的事件;二是“灰犀牛”,指的是发生概率较大的事件。

针对黑天鹅(小概率事件),我们总结出一个词:适应性。这个词源于达尔文在《物种起源》中的观点:能够生存下来的物种并非最强大的,而是最能适应环境的。面对不确定性和小概率事件,我们需要建立适应能力。适应能力的本质是快速迭代和自我改变。尽管改变是带有风险的,但我们需要基于对未来的最有可能假设,通过最小化版本进行验证,不断提升组织的适应性。

另外一个维度,灰犀牛(大概率事件),我们可以做一些长期的规划,主要关注三件事情:全球化、多云化、降本。

  • 全球化:国内存量竞争激烈,海外市场不管是基础设施、用户数量、增长空间,相对来说是蓝海,此外出海业务在监管上,也相对比较宽松;
  • 多云化:应对稳定性、业务特性,赋能商务议价的需要;
  • 降本:增长乏力,难做到开源,可以更多地做好节流。

二、技术战略选型

在技术战略选型方面,我想简单分享一下过去10年在运维领域中最重要的几个技术理念之间的关系和意义。

1、技术理念

图片

首先是ITIL(IT Infrastructure Library),它是过去IT服务管理(ITSM)的一种实践方法,其目的是通过流程来管理和控制IT服务的质量,关键在于设计适当的流程以及明确定义参与人员的角色。然而,ITIL 在实施过程中也存在一些问题,比如流程繁琐效率低,质量不一定能得到显著提升,出了质量故障往往只是让某些人背锅。

接下来是云原生(Cloud-Native),它的目标是构建和运行可弹性扩展的应用服务,关键要素包括弹性、可扩展性和高可用性。在技术方面,容器化、微服务化、服务网格、不可变基础设施和声明式API是云原生的关键技术要素。再深入一层,有云原生十二要素(https://12factor.net/zh_cn/)。

然后是DevOps,其目标是实现频繁且快速地交付软件。它强调多个团队共同合作,面向最终用户交付价值,关键技术要素是工具化和自动化。

最后是SRE(Site Reliability Engineering),其中以Google的SRE为代表。SRE是一种运用软件工程方法解决问题的方法,关注可用性、延迟、性能和容量等方面。对于SRE的软件工程能力,维基百科上有详细的解释,简单来说,就是要掌握编写代码来解决问题的能力。综上所述,我认为作为一个SRE,需要围绕着目标和手段,来理解和掌握这些技术理念,这样才能成为一个合格的SRE。

2、技术架构

在技术架构方面,我从两个视角来看:

图片

首先是应用的视角。应用的架构核心是实现应用的弹性伸缩,这可以通过以下三个方面来实现:无状态化、BaaS化(Backend as a Service)、强大的应用流量治理能力;

其次是基础设施的视角。基础架构的核心是实现资源的弹性,这可以通过以下两个方面来实现:资源的统一交付和调度、多云互联互通。

在构建技术架构时,有几个必须具备的技术能力:

  • DCI 网络(Data Center Interconnect):实现多云环境下的互联互通和高可用性;
  • K8S(Kubernetes):实现应用交付和资源调度的标准化。Kubernetes是一种容器编排平台,可帮助管理和部署容器化应用程序。
  • Istiod:一种与编程语言无关的服务治理框架。它提供了服务发现、流量管理和负载均衡等功能,使得应用的服务治理更加便捷和灵活。
  • 应用可观测性:提升故障感知、定位和恢复能力。通过监控应用的关键指标和日志信息,可以及时发现故障并进行处理。
  • 用户体验监控:改善用户体验。通过监控用户的行为和反馈,可以了解用户的需求和痛点,并及时做出相应的改进。

通过以上的技术能力构建,可以实现一个具备弹性、可扩展性和高可用性的技术架构,从而提升系统的性能和用户体验。

三、组织架构设计

在技术战略的实施中,组织架构和行为是必不可少的保障措施。下图是来自《高效能团队模式》一书的组织架构设计图,这张图在过去的两年里非常热门。图中的设计基于康威定律,进一步引申出认知负载理论,并推导出四种团队和三种交互模式。

图片

对于从事软件工程的人来说,康威定律应该是一个熟悉的概念。它的核心观点是组织架构决定系统的架构,反过来说,如果想要拥有特定的系统架构,就需要设计相应的组织架构。组织架构决定了团队之间的交互模式,而跨团队的沟通本身是有成本的,这个成本可以称为认知负载。因此,在组织设计上,我们应该尽量降低沟通成本,减少团队之间的认知负载。

举个例子,在云原生时代,涉及到操作系统、虚拟化和容器化等技术的复杂性非常高。如果一个应用开发人员需要对每一层的技术细节都了如指掌,才能完成业务开发和软件交付,那么他的认知负载将会非常大。为此,我们在实际中看到,在组织上进行了分层,例如操作系统层、虚拟化层和容器层(如Kubernetes),以屏蔽底层复杂概念,极大地降低了认知负载。

基于这个底层逻辑,这本书提出了四种团队类型:业务流团队、平台型团队、复杂子系统团队和赋能型团队。同时,还提出了三种交互模式:协作(一起做)、服务(黑盒模式)和促进(教练赋能)。

通过理解和掌握这些组织架构设计的原则和模式,我们可以成为一个更合格的团队成员,并在实际工作中降低沟通成本,减少团队间的认知负载,从而提高工作效率和团队的协作能力。

四、行为价值观引导

图片

  • SRE岗位职责:我们强调SRE的核心职责是稳定性保障,他们是稳定性的首席责任人。此外,我们也要求SRE在能力上包括平台产品的建设;
  • 团队协作:实现目标需要多个团队的协作。团队协作的首要任务是建立信任关系,并在建立了信任的基础上进行充分的沟通,以达成共同目标;
  • 复盘文化:复盘的目的是为了更好地成长,而不是用于追责。我们要总结好的经验,并将其应用到其他场景中。同时,我们也要总结教训,以避免在其他项目中重复犯错;
  • 技术卓越:我们要创造条件,使团队成员有机会追求技术卓越,并不断提升个人能力;
  • 开放连接:我们要站在巨人的肩膀上,与云厂商建立合作共赢的伙伴关系。通过这样的合作,我们可以在多个方面为团队提供支持和赋能。我们可以基于对未来的设计,共同打造一些产品能力。

最后,我想强调的是,文化不仅仅是挂在墙上的宣传语,它通过对哪些人进行奖励、提升和解雇来体现,真正的文化是通过这些行为来体现出来的。

五、具体实践路径

1、全球一张网:我们在过去两年的实践中,面临了多个VPC之间的连接问题,配置静态路由非常繁琐且容易遗忘,导致部分网络不通,引发故障。为了解决这个问题,我们提出了"全球一张网"的概念,即任意节点间实现内网互联互通,并通过简便的配置方式实现高可用的互联网络。

2、统一资源交付、统一资源调度和应用交付能力:这三个能力从效能的角度来看,包括质量、效率和成本。我们通过标准化、系统化、自动化和智能化的手段实现了这些能力。

  • 统一资源交付:通过CMP系统统一用户操作界面,避免交付动作不准确引起的问题,如定义自己的机型标准,用户无需关心系统盘大小、操作系统内核以及磁盘类型和大小;
  • 统一资源调度:将资源统一池化,以便实现标准化和简化管理。通过离线和在线业务的分时复用,最大限度提升资源利用率;
  • 统一应用交付:基于K8S的镜像化交付成为云原生应用交付的标准,实现一次构建,随处运行。结合应用资源画像,自动设置资源配置(Limit和Request)、副本数和弹性伸缩策略。

3、可观测能力:可观测能力是当前热门的方向,包括指标监控、追踪和日志记录。我们可以从用户视角出发,关注稳定性、性能和产品易用性。在市场上有很多成熟的产品可供选择,通过外部合作(购买)的方式快速具备可观测能力。

4、故障复盘能力:复盘能力是组织成长的关键。对技术团队而言,建立良性的复盘文化并非易事。以下是我们的两个经验,供参考:

  • 对于违规操作导致的故障,要进行一定的惩罚;
  • 不定义故障责任团队或者人,但必须明确故障整改措施的团队和人。很多时候我们在定义谁是故障责任人,扯皮的时间会多于真正干活解决问题的时间。

图片

通过团队的努力,我们期望成功时的样子是:

  • 随时随地拥有无限算力:能够快速交付充足的计算资源,不受地域限制;
  • 一次构建随处运行:通过制品晋级,在不同环境和地区部署同一构建物;
  • 持续改善用户体验:通过客户端监控和数据分析,不断优化用户体验;
  • 面向未来持续成长:将故障问题当成改进机会,不断提升团队能力。

六、结语

图片

基于具体的业务实践场景,并结合VUCA时代的挑战和机遇,趣丸科技形成了"云原生+DevOps+SRE+ITIL"技术理念,明确了全球一张网、统一资源交付/统一资源调度/应用交付能力、可观测能力、故障复盘能力的具体实践路径,并结合OKR进行落地,构建出了一套云原生时代下的运维技术保障体系。

刘亚丹

趣丸科技 技术保障部负责人


  • 负责公司基础架构、SRE保障、FinOps财务管理及运维产品体系,深耕互联⽹运维技术领域超15年,熟悉游戏、视频和语音直播行业运维场景。对IDC、云计算、基础架构、云原生应用架构、SRE运维保障、数据库多活和容灾、资源成本优化、运维产品规划和落地,有深入理解和大量实践,具有较为丰富的运维团队管理经验。
责任编辑:武晓燕 来源: dbaplus社群
相关推荐

2023-05-18 16:09:06

2014-08-18 16:13:15

智慧APM

2022-06-10 10:49:16

云原生监控系统

2021-01-05 10:09:28

DevOps

2014-08-07 10:45:31

长尾市场华为

2020-04-20 11:24:42

运维经验技术

2016-05-10 16:37:15

开发运维DevOps新趋势

2022-06-07 11:16:51

云原生人工智能运维

2018-09-27 08:59:29

2009-09-28 10:49:13

ITIL摩卡

2020-11-30 12:50:26

SRE运维可观测性系统

2020-12-30 11:05:51

SRE运维可观测性系统

2013-07-23 09:42:21

IBMNetflix

2022-07-26 06:30:25

SREWorks云原生

2009-10-19 15:46:14

ITIL摩卡

2012-05-11 17:02:51

IT运维ITIL

2009-06-13 15:35:51

ITILIT运维

2011-08-03 09:52:19

IT运维管理ITIL

2017-03-07 10:00:01

定义实践DevOps

2023-09-03 16:41:07

点赞
收藏

51CTO技术栈公众号