写点什么

避免不完全的云原生(二):人员和流程要素

  • 2021 年 1 月 07 日
  • 本文字数:3713 字

    阅读完需:约 12 分钟

避免不完全的云原生(二):人员和流程要素

本文最初发布于 TheStartup 博客,经原作者授权由 InfoQ 中文站翻译并分享。


注意:这是该系列文章的第 2 部分。你可以点击这里阅读第1部分,或者跳转到第345部分。


在前一篇文章中,我们讨论了云原生的实际含义,并且指出,要从云原生方法中获益,就需要从多个角度来审视它。这不仅与你使用的技术和基础设施所在的位置有关,还与你如何构建解决方案有关。但最重要的也许是,它和你如何组织员工和遵循什么流程有关。在这篇文章以及接下来的两篇文章中,我们将介绍成功迈出云原生第一步的最重要的部分,并从不同的角度进行分析。本系列文章的主题摘要如下图所示:



云原生组件


让我们从最容易被忽视的角度开始——云原生对相关人员及其所在流程的影响。


云原生要素:人员和流程


要想在云原生方法上取得成功,人员组件比其他任何组件都重要。为了实现云原生的业务价值,团队需要能够在业务和 IT 之间快速协调,以一种“低接触”的方式将更改提交到生产环境,并对所交付的内容负责,而且信心十足。任何新技术或现代架构方法都无法凭一己之力实现这一点。团队需要投入精力转向敏捷方法,采用 DevOps 原则和软件生命周期自动化,引入新的角色(例如 SRE),而且,组织必须赋予团队一定程度的自治权。下图展示了云原生方法中人员要素的一些最重要的方面:



云原生要素:人员和流程


这个列表肯定不完整。我们还认为,关于人员,还有其他方面可以提高团队弹性,超出了上面列举的要素,如转向无责备文化,鼓励成长型思维。接下来,我们将对上图中的每一项进行深入探讨。


敏捷方法


云原生基础设施和基于微服务的设计使得开发可快速更改和部署的细粒度组件成为可能。然而,如果我们没有能够用来实现交付并兑现承诺的开发方法,这将毫无意义。敏捷方法使被授权的(去中心化的)团队能够缩短变更周期,更紧密地结合业务需求,其特点如下:


  • 短而有规律的迭代周期

  • 固有的业务协同

  • 数据驱动的反馈


通常,敏捷方法会被拿来与旧有的“瀑布式”方法做对比。传统的瀑布方法会提前收集所有的需求,然后,团队在近乎隔离的状态下工作,直到他们交付最终产品供验收为止。尽管这种方法能够最小化实现团队的障碍,使他们不受变更请求的影响,但是在当今快速变化的业务环境中,最终交付物很可能与当前的业务需求不同步。


敏捷方法使用迭代开发周期,会与业务定期接触,再结合有意义的客户使用数据,可以确保项目始终专注于业务目标。其目的是根据实际的业务需求不断地修正项目的方向。


工作被分解成相对较小的、业务相关的特性,业务可以在每个发布周期中更直接地确定它们的优先级。当他们可以接受没有精确的长期交付计划,但可以确定接下来构建什么时,对业务的真正好处就出现了。


敏捷本身正在成为一个“古老的”术语,和许多术语一样,它已经遭受了近二十年的误用。然而,就目前而言,它也许仍然是对这些方法的最好的概括。

生命周期自动化


除非你缩短将新代码转移到生产环境所花费的时间,否则你无法达到你想要的敏捷程度。如果生命周期流程很慢,那么你的方法多敏捷,或者你设计的组件多轻量化,就都没有什么关系了。此外,如果反馈周期被打破,你就不能实时地对业务需求的变化做出响应。生命周期自动化主要围绕三个关键管道,它们是:


  • 持续集成——构建/测试管道自动化

  • 持续交付/部署——部署、验证

  • 持续采用——运行时更新


下图说明了它们之间的交互关系:



管道自动化(CI/CD)是 DevOps 和敏捷方法的基础


持续集成(CI)意味着经常(“持续”地)向源代码存储库提交更改,并且可以即刻进行自动构建、质量检查、相关代码集成及测试。CI 可以即时为开发人员提供反馈,让他们知道更改与当前代码库是否兼容。我们发现,基于镜像的部署使得构建管道更简单、更一致。此外,更加模块化的、细粒度的、完全解耦的无状态组件的创建简化了自动化测试过程。


CD 既可以表示持续交付,也可以表示持续部署(两个都对,尽管 Jez Humble 的著作让持续交付这个术语流行了起来,它实际上涵盖了这两个过程)。持续交付从 CI 获取输出,并执行将其部署到目标环境所需的所有准备工作,但是不部署,把最后的步骤留在审批之后,以受控的方式手动执行。当环境允许自动向环境中部署时,这就是持续部署,对敏捷的优势和潜在的风险进行了平衡。


持续采用(CA)这个术语知道的人比较少,它表示一个越来越常见的概念:保持对底层软件运行时和工具的更新。这包括 Kubernetes、语言运行时等平台。大多数供应商和开源社区已经开始按季度甚至按月进行升级。无法跟上软件的发展步伐会导致应用程序过时,变得难以更改和支持。通常,安全更新是由软件内部的管理机制强制执行的。供应商会为数量很少的旧版本提供支持,所以支持窗口一直在变短。例如,Kubernetes 每三个月发布一次,社区仅支持最近的三个版本。如上所述,CI/CD 意味着代码更改触发构建和可能的部署。企业应该自动化类似的 CA 管道,当供应商或社区发布新的升级补丁时触发这些管道。有关 CA 的更多信息,请参见持续采用


值得注意的是,生命周期自动化的效率取决于与之相关的过程。如果你的发布审批周期仍然需要几周,或者有个依赖项的生命周期以月为单位,那么将 CI/CD 周期缩短到几分钟就没有意义了。

DevOps 和站点可靠性工程


正如我们从上图中看到的,生命周期自动化为人们工作方式的更深刻变革奠定了基础。我们简化了从编码完成到将其部署到生产环境的机制,缩短了开发人员和运营角色之间的距离,甚至可能将两个角色合二为一。


这就是所谓的 DevOps,以下是其核心内容:


  • 跨开发和运营角色的协作和联合

  • 运营关切“左移”

  • 快速的运营反馈和处理


在传统环境中,开发和运营角色是严格分开的。开发人员不许接近生产环境,运营人员也很少接触软件开发的过程。这可能导致开发人员编写代码时没有考虑到生产环境的实际情况。当运营团队为了保护环境而单独引入质量门,增加进入生产环境的障碍时,这种分离就会加剧,开发和运营之间的距离会周期性地加大。


DevOps 采取的方法是,我们应该不断努力减少并尽可能消除开发和运营之间的距离,以便保持目标一致。这可以激励开发人员“左移”许多运营上关注的事项。在实践中,这可以归结为问一系列问题,然后根据答案采取行动:


  1. 我们可以使开发环境与生产环境有多相似?

  2. 我们可以将可伸缩性、可用性和可观察性测试作为早期测试的一部分吗?

  3. 我们能否从一开始就将安全性放在适当的位置,而不仅仅是在主要环境的最后才把它打开?


在这方面,容器和 Kubernetes 等平台元素可以发挥重要的作用,稍后,我们将讨论基于镜像的部署和基础设施即代码等概念,从中我们就可以看出来。


显然,使用 CI/CD 缩短开发和生产之间的路径是与 DevOps 联系在一起的,因为关注迭代和业务是敏捷方法的特点。这也意味着改变人们的工作模式。软件开发人员应该在照管生产系统方面发挥积极的作用,而不仅仅是创建新的功能。运营人员应该专注于那些可以让单调而枯燥的任务自动化的方法,这样他们就可以转向更有价值的活动,比如创建自动化程度更高的自愈环境。当这两者结合起来时,这个特定的角色通常被称为站点可靠性工程师,以强调他们也是软件工程师的事实。成功的关键是需要充分认识到,组件“失败是正常的”,因此,我们应该计划好如何管理失败,而不是徒劳地试图阻止它发生。


在理想情况下,软件开发和运营会成为一个团队,每个团队成员都可以承担开发和运营角色,彼此之间可以互换。然而,大多数组织在这方面都有某种程度的妥协,角色往往会向一端或另一端倾斜。

团队自治


如果我们使方法更加敏捷,通往生产环境的路径更加自动化,就不会扼杀这些方法所带来的生产力和创新能力。每个团队都在处理一个独一无二的问题,他们将更适合于特定的语言和工作方式。我们应该通过以下方式给予团队尽可能多的自主权:


  • 所有权去中心化

  • 技术自由

  • 自助配置


如果我们要在更细粒度的组件上快速迭代,就需要放弃“一刀切”的策略,允许更多的局部决策。正如我们稍后将讨论的那样,只要组件以一致的方式交付(例如容器镜像),一个好的云平台就理所当然地应该鼓励将构建、部署和运营标准化。为了提高生产力,团队需要能够自由决定如何实现这些组件;选择他们自己的技术,比如语言和框架。同样重要的是,确保团队能够快速完成所需工具和资源的自助配置,当然,这也符合云基础设施的特点。


在整个企业中,仍然需要在方法和技术上保持一定程度的一致性。例如,像 Spotify 模式这样的方法,通常是通过“协会(Guild)”来实现这种需求。“协会”是由团队中的个人组成的团体,他们专注于鼓励(而不是强制)团队基于自己的实际经验选择常见的方法和工具。


当然,需要注意,权力下放通常无法普遍施行,也不能一下子全部应用。它可能只对企业的某些部分有意义,或者对企业中的某些类型的计划有意义。最终,要在促进公司创新和探索以保持市场领先地位,和确保企业不会因为不断变化和日益分化而破坏核心竞争力,之间寻求平衡。


在本系列的下一部分中,我们将看一下,为充分利用云环境,我们需要做出哪些架构和设计选择。同时,如果你想了解关于这些问题的更多信息,请访问IBM Garage Method网站,在那里,我们在端到端方法的上下文中更深入地讨论了这些主题。


查看英文原文:

The “How” of Cloud Native: People and Process Perspective


延伸阅读:

云原生到底意味着什么?

避免不完全的云原生


2021 年 1 月 07 日 12:511182

评论

发布
暂无评论
发现更多内容

盘点2020 | 百度AI的2020

百度大脑

盘点2020

阿里架构师经验分享!Android面试知识点总结宝典助你通关!顺利通过阿里Android岗面试

欢喜学安卓

android 程序员 面试 移动开发

《2020年微信视频号研究报告》 | 视频号 28 天 (11)

赵新龙

28天写作

作业1

瑾瑾呀

我所认为的产品经理能力模型

day day up

案例加源码:万字长文带你彻底搞懂MySQL的索引优化

程序员小毕

MySQL sql 源码 性能优化 索引

热情空前,家长纷纷变身“寒假规划师”,如何抓住这波热潮?

ZEGO即构

AI 在线教育 在线课堂

2020中国ToB独角兽:估值逆势起飞,寡头效应加剧

ToB行业头条

WebRTC 的现状和未来:专访 W3C WebRTC Chair Bernard Aboba

阿里云视频云

阿里云 WebRTC 视频云

【有奖调研】中国人工智能开发者调研

百度大脑

合约跟单交易软件系统开发|合约跟单交易APP开发

系统开发

SpringCloud 从入门到精通 11---Nacos负载均衡

Felix

Soul网关源码阅读番外篇(一) HTTP参数请求错误

Java 源码阅读 网关

是找茬?还是装B?阿里面试每轮必问的“Spring Boot”意义何在?

比伯

Java 编程 架构 面试 计算机

IM即时通讯实现的原理

v16629866266

TarsBenchmark | 服务性能压测利器

TARS基金会

微服务 压力测试 TARS

Java 程序经验小结:返回零长度的数组或集合,而不是null

后台技术汇

28天写作

阿里架构师深入讲解Android开发!教你一种更清晰的Android架构!BAT大厂面试总结

欢喜学安卓

android 程序员 面试 移动开发

redis持久化怎么选?成年人从来不做选择...

moon聊技术

惊喜来袭!253页全彩免费电子书《Python 编程参考》正式上线发布

穿甲兵

Python Go redis 程序设计

阿里巴巴2021年最新开源十亿级Java高并发系统设计手册

Java架构追梦

Java 阿里巴巴 架构 并发 系统架构设计手册

iOS音视频--视频合集

程序员 音视频 OpenGL ES GPUImage Metal

从根上理解高性能、高并发(五):深入操作系统,理解高并发中的协程

JackJiang

网络编程 高并发 协程 高性能 即时通讯

简化业务代码开发:看Lambda表达式如何将代码封装为数据

华为云开发者社区

函数式接口 数据 代码 函数 lambad

QA为什么转换角色

BY林子

软件测试 QA 职业发展

架构师 3 期 3 班 -week8- 作业

zbest

作业 week8

COCO聊天挖矿系统开发|COCO聊天挖矿软件APP开发

系统开发

iTerm2 实现 ssh 自动登录,并使用 Zmodem 实现快速传输文件

米开朗基杨

iterm2

《我想进大厂》之分布式事务篇

艾小仙

Java 面试 后端

使用Apollo升级一下yml文件管理和发布

Sky彬

springboo

dubbo-go 白话文 | 从零搭建 dubbogo 和 dubbo 的简单用例

阿里巴巴云原生

Java 云原生 dubbo 中间件 dubbogo

聊聊IO夯的那些事

聊聊IO夯的那些事

避免不完全的云原生(二):人员和流程要素-InfoQ