采用SRE思维方式

随着云原生方法论的采用，S R E的职责也在增加。如果想让数据基础设施融合，那么SRE需要学习新的技能并付诸实践。以下是维基百科对SRE的定义（见网址列表条目[14]）：

SRE将理论和实践相结合，不仅涵盖软件工程的各个方面，还涉及在数据基础设施上应用和操作软件的问题。主要目标是创建可伸缩、高可用的软件系统。SRE和DevOps密切相关，DevOps是一套结合软件开发和信息运营的实践体系，SRE也被称为DevOps的具体实现。

过去在部署数据基础设施时，主要将注意力集中在部署的特定组件上。例如，你可能只关注规模部署的MySQL或用于分析大量数据的Spark。采用SRE思维方式则意味着除了应关注部署什么，还应关注如何部署，即让各部分协同工作来实现应用的功能。整体而言，组件的部署应当考虑交互方式、访问权限（包括安全性），以及确保满足服务等级的各方面的可观测性。

如果你的主要或次要角色是数据库管理员（DBA），那么现在正是转变的时候。据LinkedIn统计显示，DBA的数量每年都在减少（见网址列表条目[15]），而SRE的数量却在大幅度攀升。掌握运行关键数据基础设施的SRE，可以将这部分技能转化为管理云原生数据的基本能力，包括：

• 可用性

• 延迟

• 变更管理

• 应急响应

• 能力管理

为了适应并承担更多职责，SRE还需要掌握以下几项新技能：

CI/CD管道

将代码从代码库部署到生产环境中是大势所趋。在软件开发组织中，CI/CD（持续集成/持续部署）管道是能加速应用开发非常好的选择。持续集成（CI）能够在应用技术栈中编译新代码并进行完整的自动化测试，保障质量。持续部署（CD）能将经过充分测试和认证的编译版本自动部署到生产环境中。将二者结合起来（管道），开发组织能够显著提升开发速度和生产力。

可观测

DevOps从业者喜欢将问题划分为“什么”（所部署的具体服务）和“如何”（部署该服务的方法）两个环节。你如果接触过数据基础设施，就一定不会对监控感到陌生。在DevOps中的“什么”环节，可以了解部署的服务是否健康并获取诊断问题所需的信息。在DevOps中的“如何”环节，则更进一步将一切视为一个整体，你可以了解到应用是如何出现问题的。例如，在高度分布式应用中，通过分析数据在每一跳的延迟来追踪整个系统的延迟来源。

理解代码

大型分布式应用出现的故障通常不是由某个线程造成的，多数是因为代码或细微的实现过程出现BUG导致的。为了对应用的整体健康负责，你需要理解运行在指定环境中的代码。正确实施可观测性（包含软件仪表）有助于发现问题。SRE和开发人员需要定期进行明确的沟通，代码是沟通的共同基础。

拥抱分布式计算

通过Kubernetes部署应用意味着要拥抱分布式计算的方方面面。如果习惯了以往的单一系统模式，那么要实现这种转变可能有些艰难，主要在于需要转变预期想法并理解问题是在哪里出现的。例如，由于单一系统中包含了数据处理的所有步骤，因此延迟几乎为零。相比人为因素，CPU和内存才是主要症结。20世纪90年代，Sun Microsystems曾在不断发展的分布式计算领域中领先，下面列举了8个常见的错误观点（见网址列表条目[16]）：

• 网络是可靠的

• 延迟为零

• 带宽是无限的

• 网络是安全的

• 拓扑结构不会改变

• 肯定有至少一名管理员

• 传输成本为零

• 网络类型是相同的

这些错误观点都是通过一条条教训归纳出来的。但凡对其中的一个错误观点抱有幻想，结局都会令人失望，不但结果不尽如人意，而且会浪费大量查找问题的时间。从长远来看，分布式方法论值得青睐。在今后很长一段时间内，它将是部署大规模应用的手段。它就像一座高山，山顶的美景值得我们这群“登山爱好者”发起挑战，每天朝着前方乐此不疲地探索。Kubernetes应用自带分布式属性，将一一测试上述错误观点。在规划应用部署时，建议提前考虑数据转移的传输成本及影响延迟的因素，这样能节省时间，并避免重新规划。