3-云原生DevOps | 翻译自Joe Beda博客

Posted 2021-04-16 DevOps教练

‘云原生’系列博客文章

Joe Beda大牛的系列博文转发。对于Cloud Native这个词一直没有搞明白，今日搜索了一些列文章，大概翻译后分享出来。

0

正文

本文是系列博客文章的第二部分，探讨如何思考和应用“云原生”思维的多个角度。

1

文化转型

将DevOps视为文化转型可能是最有用的，开发人员必须关心他们的应用程序如何在生产环境中运行。 此外，运维人员知道并有权知道应用程序如何工作，以便他们可以主动发挥作用，使应用程序更可靠。 在这些团队之间建立理解和同情是关键。

但这可以进一步。如果我们重新审视应用程序的构建方式和运维团队的结构，我们可以改进和深化这种关系。

2

网站可靠性工程师

Google不使用传统运维团队。 Google反而定义了一种称为“网站可靠性工程师”的新型工程师 。 这些是受过高度训练的工程师（在与其他工程师相同的水平得到补偿），不仅携带寻呼机，而且希望和有能力在通过自动化推动应用程序更可靠的过程中发挥关键作用。

“第二天早上10点所发生的定义了SRE。 ”

4

激励SRE和开发团队的协作

当寻呼机在凌晨2点钟关闭时，任何人对寻呼机都做着同样的事情 - 试图找出发生了什么，以便他/她可以回去睡觉。 第二天早上10点所发生的定义了SRE。 做运维的人只是抱怨或者和开发团队一起合作保证寻呼机上出现的事情不在发生了就够了么？ SRE和开发团队有使产品尽可能可靠的激励。 这与无指责的事故分析结合，可以促成没有技术债务的健康项目。

5

SRE受人尊敬

SRE是Google里最受尊敬的人之一。 事实上，通常产品的发布并不需要SRE，而是期望开发团队在生产环境中运行他们的产品 。引入SRE的过程通常涉及开发团队向SRE团队证明该产品已准备就绪。 预计开发团队将完成所有的基础的工作，包括设置监控和警报，警报触发的工作流和发布流程。 开发团队应该能够使寻呼机收到最少的报警，大多数问题已经被自动化。

6

运维专业化

由于运维的角色变得更加复杂和特定于应用程序，因此对于单个团队拥有整个运维堆栈没有什么意义。 这导致了运维专业化的想法。在某些方面，这是一种“反奴役”。 让我们从下到上。

运维专业化

硬件运维

这已经是明显可分离的。 事实上，很容易将IaaS云看作“硬件运维即服务”。

运维专业化

操作系统运维

有人必须确保机器启动，并有一个好的内核。 从应用程序依赖性管理中突破这一点反映了集中在托管容器（ CoreOS ， Red Hat Project Atomic ， Ubuntu Snappy ， Rancher OS ， VMWare Photon ， Google Container Optimized OS ）上的最小操作系统发布趋势。

运维专业化

集群运维

在容器化的世界中，计算集群成为一个逻辑基础架构平台。 集群系统（Kubernetes）提供了一组原子操作，使许多传统运维任务能够自我服务。

运维专业化

应用运维

每个应用程序现在可以有适当的专门的应用程序团队。 如上所述，开发团队可以并且应该在必要时发挥这一作用。 这个运维团队希望在应用程序上更深入，因为他们不必是其他层面的专家。 例如，在Google，AdWords Frontend SRE小组将与AdWords Frontend开发小组讨论，而不是与集群SRE（小组）小组交谈。 这种激励的一致性可以导致更好的结果。

根据组织的需要，可能还有其他专门的SRE团队的存在空间。 例如，存储服务可以被分解为具有专业技能的SRE的单独服务。 或者可能有一个团队负责构建和验证所有团队应根据政策使用的基本容器映像。

在本系列的下一部分中 ，我们将了解Cloud Native如何与容器和容器群集相关。

• 第3部分：DevOps

• 第4部分：容器和集群

• 第5部分：微服务

• 第6部分：安全

Joe Beda简介

他的工作履历如下：

扫码加入DevOps教练的微信群

群助手1

群助手2

群助手3

群助手4