OpenShift高效运维:SRE视角的集群和分布式系统管理
上QQ阅读APP看本书,新人免费读10天
设备和账号都新为新人

第1章 概述

Manuel Dewald

运维分布式软件是一项艰巨的任务。它需要人们对他们所维护的系统有深刻的理解。无论你构建了多少自动化程序,它们都永远不会取代高技能的运维人员。

OpenShift是一个平台,旨在帮助软件团队开发和部署分布式软件。它附带了大量内置的或者很容易部署的工具。虽然它可以为用户提供很大帮助,并且可以消除许多传统的手动操作负担,但OpenShift本身是一个需要部署、操作和维护的分布式系统。

许多公司都有平台团队,他们为研发团队提供基于OpenShift的开发平台,这样维护工作就集中了,整个组织的部署模式也标准化了。这些平台团队越来越多地转向站点可靠性工程(Site Reliability Engineering,SRE)团队,其中软件开发实践被应用于操作任务。脚本被适当的软件解决方案所取代,这些解决方案可以更容易地进行测试,并使用持续集成/持续交付(CI/CD)系统自动部署。警报从简单的基于原因的警报(如“虚拟机23上使用了大量内存”)转换为基于反映客户体验的服务水平目标(Service Level Objective,SLO)的基于症状的警报,如“处理请求所需的时间比我们预期的要长”。

OpenShift提供了使用SRE范例在其上运行软件所需的所有工具,从监视平台到集成的CI/CD系统,你可以使用该系统来观察和运行部署到OpenShift集群的软件以及集群本身。但是,构建自动化、实现良好的警报策略以及最后调试在操作OpenShift集群时所发生的问题,仍然是需要熟练的运维或SRE人员的艰巨任务。

即使在SRE团队中,传统上,工程师的大部分时间都用于手工操作任务,通常称为“Toil”。不过,操作时间应该是有限制的,因为SRE的主要目标是解决软件工程的Toil。

O'Reilly出版了一系列由Google站点可靠性工程师撰写的与核心SRE概念相关的书籍(https://sre.google/books)。如果你对这些原理的细节感兴趣,我们建议你看看这些书。在第一本书Site Reliability Engineeringhttps://sre.google/sre-book/table-of-contents)中,作者主要从他们在谷歌担任SRE的经验出发,建议将Toil工作时间限制在工程团队时间的50%以内。