hello云胜

技术与生活

0%

发表于

sre1

sre和传统it运维的区别：

  1. sre深度参与开发阶段的工作，对应用的设计实现方案/依赖/运行时的资源消耗等都有严格的规约
  2. sre本身也要做很多开发工作，开发各种工具进行自动化解决运维问题和故障
  3. 按照sre的规约，由开发人员自行进行程序的上线部署和更新。

sre真正实现了devops

运维应该是作为一项工程存在，有标准和规范。不能依靠个人英雄主义。

我们运维人员应当称为这个新的名字sre。Site Reliability Engineer 站点可靠性工程师

关键词就是 软件工程理念 + 自动化工具

（题外话，感想：一个软件工程，不只是最终的成品软件和架构设计是有价值的，真实的设计过程，思考经历，经验的沉淀，总结教训都是非常有价值的。实现细节永远只是短暂的，而文档化的设计过程却是无价之宝）

软件工程有时候和养孩子很像：虽然孕育一个孩子的过程是艰辛的，但是以后的养育孩子才是更需要花费长久精力的事情。但是目前我们软件行业的关注绝大部分都集中在开发阶段，对运维阶段设计的很少。

如果说软件工程师专注于生孩子，那么sre就是专注于养孩子。进行整个软件系统的生命周期管理，从设计到部署，不断迭代，最后下线退役。

sre理念：

对细节不懈关注，做好充足的灾难预案和准备工作，时刻警惕着，不放过一切机会去避免灾难发生。

对sre的传统运维工作设置一个上限 50%。sre必须有重组的时间进行编程。设计出切实解决问题的系统。

这需要管理层的介入

sre的核心方法论

  1. 确保长期关注研发工作
  2. 在保障服务slo前提下最大化迭代速度

当前敏捷开发的主要矛盾是迭代创新的速度和产品稳定度之间的矛盾

  1. 监控系统

    一个需要人工阅读邮件和分析警报来决定目前是否需要采取某种行动的系统从本质上就 是错误的。监控系统不应该依赖人来分析警报信息，而是应该由系统自动分析，仅当需 要用户执行某种操作时，才需要通知用户

  2. 应急事件处理

    评价一个团队将系统恢复到正常情况的最有效指标，就是MTTR。平均恢复时间。

    任何需要人工操作的事情都只会延长恢复时间。 一个可以自动恢复的系统即使有更多的 故障发生，也要比事事都需要人工干预的系统可用性更高。

    应急事件的处理关键在于运维手册。SRE 将大部分工作重心放在“运维手册”的维护 上

  3. 变更管理

    大概70%的生产事故由某种部署的变更而触发。

    变更管理的最佳实践是使用自动化来完成以下几个项目：

    ● 采用渐进式发布机制。

    ● 迅速而准确地检测到问题的发生。

    ● 当出现问题时，安全迅速地回退改动。

    将人工因素排除在流程之外，变更执行的速度和安全性同时得到了 提高。

    因为人很容易被大量重复性劳动的关注疲劳所影响

  4. 需求预测和容量规划

    需求预测和容量规划简单来说就是保障一个业务有足够的容量和冗余度去服务预测中的 未来需求。

    一个业务的容量规划，不仅仅要包括自然增长(随着用户 使用量上升，资源用量也上升),也需要包括一些非自然增长的因素以应对突发情况。

    容量规划有几个步骤是必需的：

    ● 必须有一个准确的自然增长需求预测模型，需求预测的时间应该超过资源获取的 时间。

    ● 规划中必须有准确的非自然增长的需求来源的统计。

    ● 必须有周期性压力测试，以便准确地将系统原始资源信息与业务容量对应起来。

    SRE 应该主导容量规划和资源部署的过程

  5. 资源部署

    资源的 部署和配置必须能够非常迅速地完成，而且仅仅是在必要的时候才执行，因为资源通常 是非常昂贵的。而且这个部署和配置的过程必须要确保能够正确地执行完毕，

  6. 效率与性能

    SRE 可以通过模型预测用户需求，合理部署和配置可用容量， 同时可以改进软件以提升资源使用效率。通过这三个因素能够大幅度推动一个服务的效 率提升(但是并非全部)。

发表于

sre2

一个缓慢的不断重启的实例要好过一个永远不重启一直泄露资源的实例。

发表于

sre3

我们不应该试图构建一个百分之百可靠的服务。

事实证明，超过一定值后， 再提高可靠性对于一项服务(和它的用户)来说，结果可能会更差而不是更好!

极端的 可靠性会带来成本的大幅提升：过分追求稳定性限制了新功能的开发速度和将产品交付 给用户的速度，并且很大程度地增加了成本，这反过来又减少了一个团队可以提供的新 功能的数量。

此外，用户通常不会注意到一项服务在高可靠性和极端可靠性之间的差 异，因为用户体验主要是受较不可靠的组件主导，例如手机移动网络或者他们正在使用 的设备。简单地说，用户在一个有着99%可靠性的智能手机上是不能分辨出99.99%和 99.999%的服务可靠性的区别的!

基于这一点，SRE 旨在寻求快速创新和高效的服务运营业务之间的风险的平衡，而不是 简单地将服务在线时间最大化。这样一来，我们可以优化用户的整体幸福感，平衡系统 的功能、服务和性能。

我们的目标是：明确地将运维 风险与业务风险对应起来。我们会努力提高一项服务的可靠性，但不会超过该服务需要 的可靠性。也就是说，当设定了一个可用性目标为99.99%时，我们即使要超过这个目标， 也不会超过太多，否则会浪费为系统增加新功能、清理技术债务或者降低运营成本的机 会。

错误预算！！！

这个设计太牛了。非常值得在公司内部推广使用。

发表于

sre4

slo

sli

sla

SLI 服务质量指标

SLI是指一个具体的质量指标。

比如请求延迟（处理一个请求所需要的事件），错误率（请求处理失败的比率），系统吞吐量（每秒请求数量）。

可用性代表服务可用时间的百分比，是指能正确处理业务请求的时间。

运维行业经常用9的数量来描述可用程度。例如，99%可用性被 称为“2个9”,99.999%被称为“5个9”。99.95%可用被称为“3.5 个9”

SLO 服务质量目标

目标是要达到的某个SLI值或者范围。

举例来说，请求延迟的SLO目标是100ms。

不适合用qps来slo，因为qps是依赖于用户的请求。

有趣的是，经常多个sli之间会互相影响。比如qps高了之后，可能导致请求延迟也变高。

SLA 服务质量协议

是一种保证。描述了在达到或者没有达到SLO 之后的后果。

区别SLO 和 SLA 的一个简单方法是问“如果 SLO 没有达到时，有什么后果?”如果没有定义明确的后果，那么我们就肯定是在讨论 一个SLO, 而不是SLA

具体操作

SKI的选择

SLI指标是不是越多越好？当然不是，一般而言，4、5个有用的核心指标就可以了。指标过多反而会影响那些真正有用的指标。

如何选出这几个有用的指标？必须真正理解用户对系统的需求。

一般来说，sre更倾向于分析一组指标数据的百分比分布，而不是算数平均值。比如延迟50%，90%，99%的分布情况。

这样可以分析长尾效应。

我们设置指标应该从思考用户最关心的方面入手，而不是从我们现在能度量什么入手。与其选择指标，再想出对应的用户目标。不如从用户目标推到除我们需要什么指标。

按照以上的说明，我们可以输出如下的指标：

  1. 系统90%的GET 请求在1ms内完成
  2. 系统99%的GET 请求在10ms内完成
  3. 系统99.9%的GET 请求在100ms内完成

SLO的选择

SLO不是一个纯粹的技术目标，而是设计产品和业务层的决策目标。

关于SLO的建议

  1. 保持简单

  2. SLO越少越好

    一定要保证每个SLO都是必不可少的

  3. 不要追求完美

    可以在一开始用一个宽松的SLO，然后逐渐收紧。要比一开始设置了很高的SLO目标，而实际无法完成又去放松要好得多

SLA的选择

SLA更加超过SRE的职责范围。需要业务和法务团队主导。SRE主要是帮助业务和法务团队了解使用SLA的SLO目标的困难程度。避免SLA中出现难以达成的SLO

发表于

sre5

在sre的工作中，将日常运维工作称为琐事。sre不应该在琐事上花费过多的时间，而应该将时间花在长期项目的研发上。

什么是琐事？

我们在公司中的工作，会有这两类不可避免的事务：1，行政类的杂务。2，需要手工处理的脏活累活。

这两类都不是琐事。因为行政类的杂务比如周报、周会等是团队工作中必须的。优化遗留代码，清理无用配置等脏活累活也是必须的。

琐事应该是在运维工作中的手动的、重复的、长期的劳动。我们应该用技术将其自动化。比如磁盘告警处理。

SRE的一个公开目标就是保证每个SRE的工作时间中处理琐事的比例低于50%。SRE通过将更多时间花在工程项目上，以减少未来的琐事和增加服务功能。

琐事也并不是完全有害无益。低风险的重复性的工作有让人平静的功效。完成这些事会给人一种满足感和解决问题的胜利感。比如通过清理日志解决了磁盘告警。

发表于

sre6.监控

监控系统的信噪比应该很高。否则运维人员会进入狼来了的状态，怀疑监控的有效性甚至胡月警报。这就是我们常说的，警告过多等于没有警告。

监控系统应该解决两个问题：什么东西出故障了，以及为什么出故障。

即现象和原因。

在一个多层系统中，某个服务的现象可能是另一个服务的原因。比如数据库慢是数据库监控的详细，而是前端服务慢的原因。

监控系统的4个黄金指标

  1. 延迟

  2. 流量

  3. 错误

  4. 饱和度

    前面3个好理解。饱和度是指服务有多满。比如服务器的内存利用率，带宽或者IO使用情况。

​ 延迟增加通常是饱和度增加的早期现象。

发表于

sre7：自动化

自动化是一种力量倍增器。但是并不能改变力量用在哪的准确性。

自动化的价值：

  • 一致性

    人的操作无法保证一致，总有失误的时候

  • 平台性

    可扩展的平台

  • 速度快

    自动修复某些常见的故障，要比人介入后修复快得多。可以有效降低MTTR（平均修复时间）

  • 节省时间

    这里我们有时候会纠结是否有必要编写自动化代码。因为可能编写自动化代码所需要的时间要比我们手动进行100次操作的时间还长。但是建议还是应该编写自动化代码，因为代码是可以传承的。

常用工具：chef，puppet。语言 perl，python

python程序进行环境验证

幂等

最可用的工具通常是由那些每天使用它的人写成的。

自动化系统进化为自治系统。

自动化的缺点：随着时间的推移，我们越来越习惯使用自动化的工具，而直接接触系统的机会越来越少。这样不可避免的，当自动化系统出现故障时，需要我们直接运维系统，我们已经无法成功运维。

发表于

sre8 发布工程

发布工程还是一个比较新的学科，在大厂通常会有专门的同事负责软件版本的发布。

简单来说，这个学科专注于构建和交付软件。发布工程师通常对源代码管理、编译器、构建配置语言、自动化构建工具、包管理器和安装器等非常了解（甚至是这方面的专家）。他们的技能横跨很多领域：开发、配置管理、测试集成、系统管理，甚至用户支持

为保障服务可靠运行需要可靠的发布流程。SRE需要保证二进制文件和配置文件是以一种可重现的、自动化的方式构建出来的。这样每一次发布才是可以重复的

发布工程哲学

自服务模型

每个团队必须能够自给自足。发布工程师只开发工具，制定最佳实践，以便让产品研发团队可以自己掌控和执行自己的发布流程。

不会所有的项目发布都要找发布工程师。

发布过程可以自动化到基本不需要工程师干预

追求速度

面向用户的软件组件重新构建非常频繁，因为我们的目标是让用户可见的功能越快上线越好。我们同时也认为频繁的发布可以使得每个版本之间的变更减少。这种方式使得测试和调试变得更简单

密闭性

构建过程使用指定版本的构建工具（编译器），同时使用指定版本的依赖库（第三方类库）。编译过程是自包含的，不依赖于编译环境之外的其他服务。

这是为了保障在任何情况下构建出的软件包是一样的

强调策略和流程

确保在发布过程中只有指定的人才能执行指定的操作。

几乎所有对源代码的修改都需要进行代码评审，这与我们日常开发工作流程是完美结合的。

持续构建与部署

分支管理

所有的代码都默认提交到主分支上（mainline）。然而，大部分的项目都不会直接从主分支上进行直接发布。我们会基于主分支的某一个版本创建新分支，新分支的内容永远不会再合并入主分支。Bug修复先提交到主分支，再cherry picking到发布分支上。这种方式可以避免在第一次构建之后，再引入主分支上的其他的无关改动。利用这种分支与cherry picking的方法，可以明确每个发布版本中包含的全部改动。

持续测试

在每个主分支改动提交之后运行单元测试。

使用最后一个测试全部通过的软件版本来进行最新的发布。

部署

我们的目标是让部署流程与服务的风险承受能力相结合。在开发环境或者预生产环境中，我们可能会每小时构建一次，同时在所有测试通过之后自动发布更新。对于大型面向用户的服务来说，我们可能会先更新一个集群，再以指数速度更新其他集群直到全部完成。对敏感的基础设施服务来说，我们可能会将发布扩展到几天内完成，根据这些实例所在的地理位置交替进行。

发布工程经常是“事后诸葛亮”，随着平台和服务的规模与复杂度不断增加，这种理念一定需要改变。

团队应该在开发流程开始时就留出一定资源进行发布工程工作。尽早采用最佳实践和最佳流程可以降低成本，以免未来重新改动这些系统。

发表于

k8s中Jenkins错误处理

mvn编译错误

image-20231219171135637

1
2
3
4
+ mvn clean package -Dmaven.test.skip=true -Ptest
Error: missing `server' JVM at `/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.232.b09-0.el7_7.i386/jre/lib/i386/server/libjvm.so'.
Please install or use the JRE or JDK that contains these missing components.
script returned exit code 4

这种情况是偶然出现，代码和环境都没有改动。

目前排查大概率的原因是nfs和centos配合上的bug

在网上看到这种说法

img

但是我这边用的是nfs

然后又再次运行了流水线，结果成功了。。没有能够复现。所以需要以后遇到的时候继续验证