你在使用哪种编程语言?快来投票,亲手选出你心目中的编程语言之王 了解详情
写点什么

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

2021 年 1 月 07 日

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

本文最初发布于 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:511108

评论

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

打造Django私有化缓存组件django-api-cache

pygodnet

django django-api-cache django缓存 私有化缓存 接口缓存

讲述我在阿里六面的经历,幸好我掌握了这份“Java并发编程+面试题库”成功拿到20K的offer

比伯

Java 编程 架构 面试 计算机

我在阿里巴巴做 Serverless 云研发平台

阿里巴巴云原生

Serverless 容器 开发者 云原生 CloudNative

架构师训练营 1 期 -- 第十一周总结

曾彪彪

极客大学架构师训练营

腾讯T4Java大牛连续半个月每天熬夜到凌晨三四点,竟然就只是为了写一份MyBatis源码学习笔记

Java成神之路

Java 程序员 架构 面试 编程语言

mysql的这些坑你踩过吗?快来看看怎么优化mysql?

比伯

Java 编程 架构 面试 计算机

ONES 收购知名协作工具 Tower

万事ONES

团队协作 高效 研发管理工具 收购 资讯

架构师训练营第二周框架设计课后练习

Geek_xq

《迅雷链精品课》第十课:共识算法理论基础

迅雷链

区块链

挑战赛 | 话题王者VS互动先锋(第一季)

InfoQ写作平台官方

话题讨论 活动专区

性能压测

jorden wang

已拿腾讯后台开发岗offer,简单说下自己的面试经历和学习路线

程序员小灰

c++ 后台开发 架构师 TCP/IP Linux服务器开发

程序员的故事

Philips

敏捷开发 快速开发 原创小说 企业开发 企业应用

蘑菇街Java大牛纯手写熬夜肝出的《Spring MVC源码笔记》赶紧收藏

Java成神之路

Java 程序员 架构 面试 编程语言

赶紧收藏!Java大牛熬夜一周肝出的《Spring AOP/IOC源码笔记》

Java成神之路

Java 程序员 架构 面试 编程语言

每周学点TARS——服务自定义命令

TARS基金会

c++ DevOps 后端 TARS

即使不会node.js,拖拽就可完成数据的可视化展示

华为云开发者社区

node.js 数据 可视化

新闻|Babelfish使PostgreSQL直接兼容SQL Server应用程序

PostgreSQLChina

数据库 postgresql 开源

训练营第七周作业

大脸猫

极客大学架构师训练营

接口测试怎么进行,如何做好接口测试

测试人生路

软件测试 接口测试

给你一个亿的keys,Redis如何统计?

不才陈某

redis

ONES 收购 Tower,五源资本合伙人对话两位创始人

万事ONES

项目管理 团队协作 ONES Tower 收购

技巧收藏|10个JavaScript常用数组操作方法

华为云开发者社区

Java 数组 开发

年轻人想详细了解做了十年Linux跟做了十年Windows的程序员差距有多大吗?听我慢慢道来!

ShenDu_Linux

Linux 程序员 windows

「更高更快更稳」,看阿里巴巴如何修炼容器服务「内外功」

阿里巴巴云原生

容器 运维 云原生 双十一 CloudNative

京东T7架构师手写的10万字Spring Boot详细学习笔记+源码免费下载

Java成神之路

Java 程序员 架构 面试 编程语言

腾讯大牛整合Java+spring5系统学习架构,神乎其技

小Q

Java 学习 编程 面试 spring 5

一个真正0基础小白学习前端开发的心路历程

华为云开发者社区

开发 开发小白 0基础

想了解任务型对话机器人,我们先从自然语言理解聊起

华为云开发者社区

人工智能 机器人 自然语言

值得学习!阿里P8架构师“墙裂”推荐:Java程序员必读的架构书籍

Java成神之路

Java 程序员 架构 面试 编程语言

《前端实战总结》之使用CSS3实现酷炫的3D旋转透视

徐小夕

css3 前端 前端工程 CSS小技巧

技术为帆,纵横四海- Lazada技术东南亚探索和成长之旅

技术为帆,纵横四海- Lazada技术东南亚探索和成长之旅

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