使用python openyxl库完成对execl文件的读写

leetcode 数据题

leetcode 数据题

介绍一些kafka大集群运维遇到的相关case

讲述如何从头搭建的这个博客.

变更管理一词有两种解释：组织变更管理和变更控制。本章将变更管理作为所有方法的集合术语，用于准备和支持个人，团队和业务单位进行组织变革。我们不会在项目管理环境中讨论这个术语，它可以用来指代变更控制流程，例如变更审核或版本控制。

本章给出了一个从无人值守到成熟SRE组织的路线图。无论你的SRE团队中处于什么阶段或位置，本章都将帮助你如何发展SRE团队。

距离我们开始在Google上练习SRE已有14年了。 回想起来，当时的一些成果似乎是显而易见的，而其他发展则令人震惊。 我们出版第一本SRE书的两年以来特别有趣。 现在正在实施SRE的公司数量以及我们在会议和客户的谈论中关于它的时间已经超出了我们之前的想象。特别是这种变化 -- 围绕SRE的非谷歌生态系统的快速扩张 - 是最令人兴奋的，但它使得预测SRE行业的未来变得更加困难。 尽管如此，我们自己在谷歌的SRE工作中，开始看到一些可能为行业未来提供概述信息的趋势。 本章代表了我们分享 自己以及全球SRE同事所看到的，以及迄今为止所努力得出的结论。

本章采用某SRE团队的视角，该团队准备为新服务提供支持。我们着眼于如何与负责该服务的开发和产品团队一起有效地提供服务。虽然SRE通常“参与”一个或多个服务，但“参与”所涉及的内容远不止服务本身——它侧重于理解开发和产品团队的目标，并找到支持他们的正确方法。

无论其起源如何，过载都是一种可能削弱生产力的职业压力。如果不加以控制，可能会导致严重的疾病。当团队没有足够的时间来处理这些"负载"时，通常会发生工作超负荷——当分配给团队的任务数量无法在每个任务的给定截止日期内完成时，这是客观现实。

在部署系统的新版本或其关键组件(如配置或数据)时，我们将变更(通常未公开给真实输入的更改，如面向用户的流量、或用户提供的批处理数据)打包。变更会带来新的特性和功能，但也存在部署之后出现问题的风险。我们的目标是通过测试一小部分流量来降低风险，以确保没有任何不良影响。我们将在本章后面讨论评估过程。灰度过程还让我们对变更充满信心，因为我们将其暴露给越来越大的流量。为变更引入实际生产流量还使我们能够识别在单元测试或负载测试等测试框架中可能不可见的问题，这些问题通常更为人为。

在项目生命周期的开始阶段，配置通常相对轻量且简单。您可能有一些数据格式的文件，如INI，JSON，YAML或XML。管理这些文件几乎不需要辛劳。应用程序、服务器和变体的数量随着时间的推移而增加，配置可能变得非常复杂和冗长。如果项目充斥着与配置相关的工作，您可以采取一些基本策略来改善这种情况。

系统配置是SRE经常要面对的问题。这是一项繁琐的工作，有时还会让人沮丧，特别是当工程师不熟悉系统，或是系统配置目标不够清晰时这种情况更为明显。系统配置常见的场景如下：在系统初始阶段的配置设计，出现事故时的紧急配置设计。本章基于经验和策略，以基础架构系统工程师的角度来进行系统配置，从而达到“安全和可持续”的目标。

为了满足越来越大的数据集的处理需求，以及密集的数据转换和快速，可靠和低成本获得结果的需求。当前广泛需要处理的数据源有很多——从移动使用统计到集成传感器网络，再到Web应用程序日志等。数据处理管道目标是将这些无限、无序、全球规模的数据集转换为结构化的索引存储，来帮助关键业务决策或解锁新产品功能。

非抽象大系统介绍设计

服务永远不会100％可用：比如突发的流量高峰导致系统崩溃；或者船锚意外扯住了跨大西洋的光缆造成网络不可用。作为服务提供者，我们要为客户提供持久稳定的服务。面对这些突发的情况，如何才能使我们的基础设施尽可能具备可靠性？本章介绍了Google应对过载的方法，希望能够使用这些最佳实践来提高服务的可靠性和可用性。多年来，我们发现，没有单一的解决方案来均衡和稳定网络负载。因此，多种工具、技术和策略的组合才是帮助保持我们的服务可靠性的方法。在我们深入讨论本章之前，我们建议阅读《SRE：Google运维解密》第19章《前端服务器的负载均衡》和20《数据中心内部的负载均衡系统》中的内容。

故障无法避免，重要的是故障发生之后，通过一种什么样的手段去避免/预发此类故障的再次发生：事后总结。优秀的事后总结，可以采取行动并广泛分享，事后总结可以成为积极推动组织变革和防止重复故障的利器。为了可以说明优秀的事后总结的写作原则，本章介绍了一个曾经发生在Google的故障案例进行研究。

对于大规模、或需要多人协作/协调解决的故障，如何以有效的方式协调团队的响应工作，并确保响应者和利益相关者之间的信息流通。包括谷歌在内的许多科技公司都有自己的“最佳实践”来管理应急响应，并且在不断的完善。

On-call轮值是很多运维和研发团队的重要职责，这项任务的目标是保障服务的可靠性和可用性，但是，不正确的Oncall轮值制度执行将会给服务甚至团队到来非常严重的后果，本章描述Google和Evernote的轮值方法，以及案例。

可靠性只有靠对最大程度的简化不断追求而得到 -- `C.A.R.Hoare, Turing Award lecture`

SRE要把更多的实践花费在长期项目研发而非日常运维中，因为术语日常运维可能会被误解，因此我们使用专门的赐予进行描述--琐事(toil)，琐事就是运维服务中手动性的、重复性的、可以被自动化的、战术性、没有持久价值的工作。

本章介绍如何在发生重要事件时将SLO转换为可进行配置的报警。并且通过示例展示了一系列报警指标和逻辑的复杂实现；讨论他们的功能和缺点。虽然我们的示例使用的是简单的request-driven服务和Prometheus语法，但你可以应用到任何报警框架中。

可靠的运维一个系统的前提是：如何去衡量一个服务最重要的基础指标、这些指标的预期值，以及当指标不符合预期事的应对计划。第2、4、5章分别介绍如何去为什么需要指标，如何去获取这些指标、当这些指标不符合预期如何报警？本章介绍了Google的SRE团队在构建监控系统和报警系统方面遵循一些核心思想和最佳实践。

SLO工程案例学习

可靠的运维一个系统的前提是：如何去衡量一个服务最重要的基础指标、这些指标的预期值，以及当指标不符合预期事的应对计划。第2、4、5章分别介绍如何去为什么需要指标，如何去获取这些指标、当这些指标不符合预期如何报警？

DevOps SRE两种解决方案产生的背景、以及二者之间的联系与区别。

《SRE Google运维实践》 综述; Google SRE系列的第二本书。是对第一本书说描述的内容的更详细的解读。