DevOps

DevOps intelligentx

CD/CD

Chinese, Simplified
SEO Title
CI CD

【CD/CD】不要让安全在在CI / CD环境中落后

Chinese, Simplified

持续集成(CI)和持续交付(CD)或CI / CD是Agile和DevOps软件开发方法的一部分。敏捷开发最突出的方面 - 也是最重要的规则 - 是它要求软件开发通过迭代过程对变化做出响应。

但是软件开发项目通常需要大量代码,这需要时间来编写。错误可能无法识别,并且由于不同的团队正在进行不同的工作,冲突可能会在未检测到的情况下一直滑到过程的后期。这不是敏捷。

CI和CD为这些常见问题提供了解决方案,允许更频繁,更可靠地进行代码更改。安全性是这种可靠性的一部分,但在CI和CD过程中经常会被忽略。

什么是CI / CD,为什么要实施它?


持续集成是一种软件开发方法,要求开发人员按常规计划将代码集成(签入)到共享存储库。代码通常至少每天检查一次,但正确的频率实际上取决于代码更改的频率。

每次登记都由自动构建验证。检测到错误并立即解决。

持续交付基于持续集成,使用自动化解决方案快速部署软件应用程序。在开发过程中通常使用多个环境,例如测试和生产,CD确保有一种自动机制可以快速将代码更改推送到所有环境。 CD还可以自动执行对Web服务器或数据库的所需服务调用,并在进行代码更新时根据需要重新启动数据库。

幸运的是,您不必构建自己的CI系统。有一些工具可以提供一个开箱即用的工具:

  1. Jenkins是一个可扩展的自动服务器,可用作基本的CI服务器。它是一个基于Java的程序,包含适用于Windows,Mac OS X和其他类Unix操作系统的软件包。 Jenkins包括错误检查和内置帮助,它通过Web界面进行简单配置。
  2. TeamCity是JetBrains的基于Java的CI服务器。它允许您在提交源代码更改之前构建,检查和运行自动化测试。进度报告确定了开发过程中的问题


CI和CD的好处包括:

  1. 敏捷 - 敏捷的软件开发方法通常将工作分解为一周或两周的冲刺,因此应用程序是逐步构建的。如果开发人员等到每个sprint结束时集成他们的工作,那么定位和解决错误需要更长的时间。使用CI,频繁的集成可以立即识别错误。它们在识别时得到解决,在开发结束时减少了问题。
  2. 更快的部署 -  CI / CD是构建软件的更快捷方式。频繁的签入和代码测试可以防止您的团队在错误或冲突长时间未被发现的情况下重写大量代码。
  3. 更好的质量 - 开发人员在使用CI / CD时花费更少的时间来修复错误。他们有更多时间专注于更高附加值的任务,例如可用性测试。

为了更深入地了解CI / CD流程,包括最佳实践,我们建议您下载此白皮书。

为什么不能忘记安全性以及如何构建它


请记住,CI和CD的目的是生成可靠的软件。根据定义,这意味着它必须是可信任的。它必须是安全的。

作为DevSecOps方法的一部分,安全性需要从一开始就得到解决,并且应该在整个应用程序生命周期中保持高优先级。他们应该批准整个CI / CD流程以确保其安全,而不是安全团队批准每个软件版本。安全性还应该能够随时监视和运行对进程的安全检查。

让我们看一下流程中的每个步骤,看看如何构建安全性:

CI / CD管道本身的安全性


只要您的团队在设置CI / CD管道时遵循DevSecOps的最佳实践,这不应该成为主要关注的领域。但值得注意的是,这不应该被忽视。

应该跟踪到系统的登录,推送更改应该要求身份验证,并且构建应该存储在安全的服务器上。

集成开发环境(IDE)拉动


在开发人员甚至提交代码之前,应该使用静态分析工具来检查代码是否存在漏洞和编码错误。这些工具易于设置,并且通过在开发过程中识别问题从长远来看节省时间。

这样可以最大限度地减少流程后期所需的代码审查量。示例包括Eclipse,Visual Studio和SpotBugs的Veracode插件。

CI Build


静态应用程序安全性测试(SAST)工具可用于确保代码没有漏洞。 SAST工具从内部检查应用程序,查看源代码,字节代码或应用程序二进制文件以查找安全漏洞。

作为构建过程的一部分,还必须扫描任何第三方代码以确保安全性。假设第三方代码已经过充分测试是不安全的。许多第三方组件也存在零日披露的漏洞,或者依赖于其他具有漏洞的第三方组件。即使你使用的是好的,它可能依赖于不是的代码。必须使用SAST和其他工具来确保不向应用程序引入不安全的代码。

此外,这些工具可以并且应该集成到您的CI环境中。示例包括OWASP依赖关系 - 检查第三方组件检查和Checkmarx for SAST工具。

应用程序部署到开发和测试环境中


验证代码后,将其部署到开发环境中。此时,您需要检查应用程序的运行版本是否存在漏洞。

这可以通过渗透测试工具完成,例如OWASP ZAP和动态应用程序安全测试(DAST)工具。 DAST工具从外部接近应用程序,模仿“机器人攻击者”来发现漏洞。

此过程中使用的任何工具都应该快速运行,因为CI / CD的目的是快速发布。隔夜测试可用于运行更长的代码扫描,以便进行更深入的安全检查。

完全部署到生产环境后,应继续进行安全测试。新的威胁和漏洞不断涌现,因此您无法假设您的代码是安全的。有关SAST工具,DAST工具和其他应用程序安全测试工具的更多详细信息,请参阅我们的博客。

如何在CI / CD管道中有效管理安全性


在CI / CD管道的所有阶段使用各种应用程序安全测试工具是确保应用程序始终处于生产就绪状态的唯一方法。但是,管理所有这些工具的结果可能很困难。

最简单的方法是使用应用程序漏洞管理器。这种类型的DevOps工具不是另一种测试工具。相反,它结合了结果并释放了测试工具的真正力量和潜力。

应用程序漏洞管理器:

  1. 重复结果,使用一组结果而不是混合格式的多个报告提供一个报告。
  2. 通过识别存在漏洞的特定代码行来协助补救管理。
  3. 执行合规性检查,根据HIPAA,国防信息系统机构安全技术实施指南(DISA-STIG)和支付卡行业数据安全标准(PCI DSS)等法规验证您的代码。
  4. 提供混合分析。混合分析结合了SAST和DAST工具的结果,确定哪些潜在漏洞实际可利用,因此您可以先解决最重要的问题。
  5. 允许工作流程集成。与开发人员已经在其中工作的环境集成的工具使得将安全性保持为流程的一部分变得简单。寻找一种工具,为Eclipse,IDE,Jenkins,Visual Studio,Intellij,Burp Suite和OWASP ZAP等流行环境提供插件。

CI / CD是敏捷和DevOps软件开发方法中的重要一步。但是不能牺牲安全性来支持速度。相反,必须将安全性整合到流程的每个步骤中。快速安全的版本是真正成功的CI / CD流程的产物,可以生成对最终用户有价值的软件,并保护这些用户和公司免受漏洞攻击。

原文:https://codedx.com/dont-leave-security-behind-in-your-ci-cd-environment/

本文:http://pub.intelligentx.net/dont-leave-security-behind-your-cicd-environment

讨论:请加入知识星球或者小红圈【首席架构师圈】

SEO Title
Don’t leave security behind in your CI/CD environment

【DevOps】 创建您的第一个 CI/CD 管道!!

Chinese, Simplified

什么是 CI/CD 管道?


CI/CD 管道是为了交付新版本的软件而必须执行的一系列步骤。CI/CD 管道引入了监控和自动化来改进应用程序开发过程,特别是在集成和测试阶段,如以及在交付和部署期间。尽管可以手动执行 CI/CD 管道的每个步骤,但 CI/CD 管道的真正价值是通过自动化实现的。
CI/CD 管道的元素

  • Build — 编译应用程序的阶段。
  • 测试——测试代码的阶段。这里的自动化可以节省时间和精力。
  • 发布——应用程序交付到存储库的阶段。
  • 部署——在这个阶段,代码被部署到生产环境中。
  • 验证和合规性——验证构建的步骤取决于组织的需求。图像安全扫描工具,如 Clair,可以通过将图像与已知漏洞 (CVE) 进行比较来确保图像质量。

Tools

Overview

这就是我们将在本文中创建的内容。


我们用什么?

  • Ec2 Ubuntu
  • Java, Jenkins, Maven
  • Tomcat
  • Docker


设置


1:准备2台Ubuntu服务器。 为“詹金斯”命名一个。 一个为“Tomcat” 推荐超过 t2.small 实例类型。

2:确保您可以 ssh 进入两台服务器。

设置 Jenkins 服务器


1:更新


sudo apt-get update -y

2:安装Java(Java运行环境)


sudo apt search openjdk

3:安装JDK


sudo apt-get install default-jdk -y

4:检查你的版本

ubuntu@jenkins:~$ javac -version
javac 11.0.13ubuntu@jenkins:~$ java -version
openjdk version "11.0.13" 2021-10-19
OpenJDK Runtime Environment (build 11.0.13+8-Ubuntu-0ubuntu1.20.04)
OpenJDK 64-Bit Server VM (build 11.0.13+8-Ubuntu-0ubuntu1.20.04, mixed mode, sharing)


5:添加 Jenkins 存储库

curl -fsSL https://pkg.jenkins.io/debian/jenkins.io.key | sudo tee \
    /usr/share/keyrings/jenkins-keyring.asc > /dev/null
echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \
    https://pkg.jenkins.io/debian binary/ | sudo tee \
    /etc/apt/sources.list.d/jenkins.list > /dev/null


6:安装詹金斯

sudo apt update
sudo apt-get install jenkins


7:确认它正在运行。

ubuntu@jenkins:~$ sudo systemctl status jenkins
● jenkins.service - LSB: Start Jenkins at boot time
     Loaded: loaded (/etc/init.d/jenkins; generated)
     Active: active (exited) since Fri 2021-12-31 23:28:46 UTC; 57s ago
       Docs: man:systemd-sysv-generator(8)
      Tasks: 0 (limit: 2355)
     Memory: 0B
     CGroup: /system.slice/jenkins.serviceDec 31 23:28:45 jenkins systemd[1]: 
Starting LSB: Start Jenkins at boot time...
Dec 31 23:28:45 jenkins jenkins[4565]: Correct java version found
Dec 31 23:28:45 jenkins jenkins[4565]:  * Starting Jenkins Automation Server jenkins
Dec 31 23:28:45 jenkins su[4599]: (to jenkins) root on none
Dec 31 23:28:45 jenkins su[4599]: pam_unix(su-l:session): session opened for user jenkins 
by (uid=0)
Dec 31 23:28:45 jenkins su[4599]: pam_unix(su-l:session): session closed for user jenkins
Dec 31 23:28:46 jenkins jenkins[4565]:    ...done.
Dec 31 23:28:46 jenkins systemd[1]: Started LSB: Start Jenkins at boot time.


还要检查 IP + 端口 8080 以查看控制台。

请输入此命令检查密码。

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

8:安装推荐的插件

插件安装完成后,进入控制台,选择“manage jenkins”

完成之后,

9:安装Docker


更新 apt 包索引并安装包以允许 apt 通过 HTTPS 使用存储库:

sudo apt-get update
sudo apt-get install \
    ca-certificates \
    curl \
    gnupg \
    lsb-release


添加 Docker 的官方 GPG 密钥:


curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg


使用以下命令设置稳定存储库。要添加 nightly 或 test 存储库,请在以下命令中的单词 stable 之后添加单词 nightly 或 test(或两者)。


echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null


安装 Docker 引擎


更新apt包索引,安装最新版本的Docker Engine和containerd,或者下一步安装具体版本:

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io


列出您的存储库中可用的版本:

apt-cache madison docker-ce

使用第二列中的版本字符串安装特定版本,例如,


sudo apt-get install docker-ce=5:20.10.12~3-0~ubuntu-focal docker-ce-cli=5:20.10.12~3-0~ubuntu-focal containerd.io


通过运行 hello-world 映像来验证 Docker 引擎是否已正确安装。


sudo docker run hello-world

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
2db29710123e: Pull complete 
Digest: sha256:2498fce14358aa50ead0cc6c19990fc6ff866ce72aeb5546e1d59caac3d0d60f
Status: Downloaded newer image for hello-world:latestHello from Docker!
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bashShare images, automate workflows, and more with a free 
Docker ID:
 https://hub.docker.com/For more examples and ideas, visit:
 https://docs.docker.com/get-started/

 

检查状态

ubuntu@jenkins:~$ sudo systemctl status docker
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-12-31 23:40:27 UTC; 4min 55s ago
TriggeredBy: ● docker.socket
Docs: https://docs.docker.com
Main PID: 6261 (dockerd)
Tasks: 9
Memory: 34.4M
CGroup: /system.slice/docker.service
└─6261 /usr/bin/docke


让我们将我们的用户名添加到 docker 组


sudo usermod -aG docker jenkins


安装 Maven

sudo apt updatesudo apt install mavenubuntu@jenkins:~$ mvn -version
Apache Maven 3.6.3
Maven home: /usr/share/maven
Java version: 11.0.13, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "5.11.0-1022-aws", arch: "amd64", family: "unix"


设置 Tomcat 服务器


1:安装java(请看前面的步骤)


ubuntu@tomcat:~$ java -version
openjdk version "11.0.13" 2021-10-19
OpenJDK Runtime Environment (build 11.0.13+8-Ubuntu-0ubuntu1.18.04)
OpenJDK 64-Bit Server VM (build 11.0.13+8-Ubuntu-0ubuntu1.18.04, mixed mode, sharing)


2:安装tomcat

mkdir /prod
cd /prod
sudo wget https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.56/bin/apache-tomcat-9.0.56.zip
sudo apt install unzipsudo unzip apache-tomcat-9.0.56.zip

3:启动tomcat

cd apache-tomcat-9.0.56/bin
chmod +x catalina.sh
ubuntu@tomcat:/prod/apache-tomcat-9.0.56/bin$ sudo bash startup.sh
Using CATALINA_BASE:   /prod/apache-tomcat-9.0.56
Using CATALINA_HOME:   /prod/apache-tomcat-9.0.56
Using CATALINA_TMPDIR: /prod/apache-tomcat-9.0.56/temp
Using JRE_HOME:        /usr
Using CLASSPATH:       /prod/apache-tomcat-9.0.56/bin/bootstrap.jar:
/prod/apache-tomcat-9.0.56/bin/tomcat-juli.jar
Using CATALINA_OPTS:   
Tomcat started.

我们可以看到它正在运行。
4:配置设置(对于tomcat 9)

sudo vi /prod/apache-tomcat-9.0.56/webapps/manager/META-INF/context.xml

请注释掉
添加 <role rolename="manager-gui"/>
添加 <user username="tomcat" password="<yourpassword>" roles="manager-gui"/>

另外,我们需要添加用户名

cd ../bin/
ubuntu@tomcat:/prod/apache-tomcat-9.0.56/bin$ sudo bash shutdown.sh
ubuntu@tomcat:/prod/apache-tomcat-9.0.56/bin$ sudo bash startup.sh

在 Jenkins 中创建构建管道


创建一个新项目(管道)

为您的新项目提供一个名称(例如 Pipeline webapp)并选择 Multibranch Pipeline

单击添加源按钮,选择要使用的存储库类型并填写详细信息。

输入您的 GitHub 存储库地址,然后单击验证。

https://github.com/meibutuoyaji/webapp.git

如果没有凭据,则显示正常,然后单击保存。
保存后,您可以在控制台上看到它。

转到您在前面步骤中放置的 GitHub 存储库并在那里创建新文件。

制作一个名为“jenkinsfile”的文件和里面

pipeline {
    agent { docker { image 'maven:3.8.4-openjdk-11-slim' } }
    stages {
        stage('build') {
            steps {
                sh 'mvn --version'
            }
        }
    }
}

如果这篇文章对您有帮助,请点击下方的鼓掌👏按钮数次以表示您对作者的支持👇

原文:https://faun.pub/devops-create-your-first-ci-cd-pipeline-ed054ba1404f

本文:https://jiagoushi.pro/node/2052

SEO Title
[DevOps] Create your first CI/CD pipeline!!

DataOps

Chinese, Simplified
SEO Title
DataOps

【DataOps】理解DataOps

Chinese, Simplified

DataOps(数据操作)源于敏捷哲学。它严重依赖自动化,注重提高计算机处理的速度和准确性,包括分析、数据访问、集成和质量控制。DataOps开始时是作为一个最佳实践系统,但逐渐成熟为处理数据分析的全功能方法。此外,它依赖并促进分析团队和信息技术运营团队之间的良好沟通。

从本质上讲,DataOps是关于简化管理数据和创建产品的方式,并将这些改进与业务目标协调起来。例如,如果公司的目标是降低客户流失率,那么客户数据可以用来开发一个推荐引擎,根据特定客户的兴趣为他们提供产品——潜在地为这些客户提供他们想要的产品。

然而,实现一个DataOps项目确实需要一些劳动力和组织(以及一些资金)。数据科学团队必须能够访问构建推荐引擎和部署工具所需的数据,然后才能将其与网站集成。实施一个DataOps计划需要仔细考虑组织的目标和预算问题。

消除对敏捷、DevOps和DataOps的混淆

2001年的敏捷宣言表达了一些有远见的软件开发人员的想法,他们认为“开发软件”需要彻底的重新思考,包括逆转一些基本假设。比起过程和工具,这些创新的思考者更看重个人和互动。他们还强调在软件上工作,而不是全面的文档,响应变化而不是陷入计划,并且更喜欢客户协作,而不是合同谈判。敏捷指的是一种专注于客户反馈、协作和小而快速的发布的哲学。DevOps诞生于敏捷哲学。

DevOps是指将开发团队(代码创建者)和操作团队(代码用户)结合在一起的一种实践。DevOps是一种软件开发实践,它关注于这两个团队之间的交流、集成和协作,其目标是快速部署产品。

DevOps的想法产生于2008年,当时Andrew Clay Shafer和Patrick Debois正在讨论敏捷基础架构的概念。这个想法在2009年在比利时举行的第一次DevOpsDays活动中开始传播。一场关于希望在软件开发中提高效率的对话逐渐演变成一个反馈系统,旨在改变传统软件开发的各个方面。变更的范围从编码到与各种涉众的沟通,并继续部署软件。

DataOps诞生于DevOps哲学。DataOps是敏捷和DevOps哲学的扩展,但侧重于数据分析。它不固定于特定的体系结构、工具、技术或语言。它是故意灵活的。支持数据ops的工具促进协作、安全性、质量、访问、易用性和编排。

DataOps最初是由《信息周刊》特约编辑Lenny Liebmann在一篇题为“为什么DataOps对大数据的成功至关重要的3个原因”的文章中介绍的。在2017年,随着大量分析师的报道、调查、出版物和开源项目的出现,DataOps的增长迅猛。2018年,Gartner将DataOps列入了数据管理的宣传周期(对新技术生命周期的预测)。

DataOps有自己的宣言,并关注寻找方法来减少完成数据分析项目所需的时间,从最初的想法开始到完成用于交流的图形、模型和图表。它通常使用SPC(统计过程控制)来监控数据分析过程。使用SPC,对数据流进行持续监控。如果出现异常,数据分析团队将收到自动警报通知。

数据ops的好处

DataOps的目标是促进数据科学家、IT人员和技术人员之间的协作,让每个团队同步工作,更快、更智能地利用数据。数据管理越好,数据就越好,可用性也越好。大量的数据和更好的数据会导致更好的分析。这反过来又会转化为更好的洞察力、更好的商业策略和更大的利润。下面列出了开发DataOps程序的五个好处:

  • 数据问题/解决能力:已经说过,创建的数据量每12到18个月翻一番。DataOps帮助将原始数据材料快速而有效地转化为有价值的信息。
  • 增强的数据分析:DataOps促进了多面分析技术的使用。旨在引导数据通过所有分析阶段的新机器学习算法正越来越受欢迎。这些算法帮助数据专家在将数据交付给客户之前收集、处理和分类数据。它还能在尽可能短的时间内提供来自客户的反馈,并促进对快速变化的市场需求的快速反应。
  • 寻找新的机会:DataOps打开了灵活性的大门,并改变了组织内的整个工作流程。优先事项发生了变化,新的机会作为范式转变的一部分出现了。它有助于建立一个办公室和部门之间没有界限的新生态系统。各种各样的人员,如开发人员、操作员、数据工程师、分析师和市场顾问可以实时协作,计划和组织各种方式来实现企业目标。将不同的专家聚集在一起的协同作用加快了响应时间,并提供更好的客户服务,从而增加了企业的利润。
  • 提供长期指导:DataOps促进战略数据管理的持续实践。它使用多租户合作来帮助协商不同客户机的需求。数据专家可以组织数据、评估数据源和研究来自客户的反馈。实现机器学习数据操作可以自动化这些过程(以及更多),使业务更加高效。

DataOps应该被视为双向街道,支持数据源和数据用户之间全面的互操作性(交换和使用信息)。通过使用自动流程,数据分析和数据管理变得更加精简。这些步骤确保了产品交付和部署的快速和无缝改进。

连续的分析

持续分析是最近才发展起来的。它不再使用复杂的批处理数据管道和etl,取而代之的是云和微服务。连续数据处理支持实时交互,并在使用更少资源的同时提供即时洞察。

连续方法被设计为同时运行多个无状态(不保存数据)引擎,这些引擎丰富、分析和操作数据。由此产生的“持续分析”方法提供了更快的答案,同时也使IT工作更简单、更便宜。

传统上,数据科学家与IT开发团队是分离的。他们的技能(数学、统计和数据科学)使他们与众不同。然而,连续交付方法让大数据团队可以在缩短的周期内发布他们的软件。在这种情况下,数据科学家使用与普通程序员相同的代码库来编写代码。数据科学家将他们的代码保存在Git中,编写连接到数据源的api的程序员也是如此。大数据和DevOps工程师用Ansible和Docker编写剧本和脚本。测试通常是过程的自动化部分。

从本质上说,持续分析是持续交付软件开发模型的扩展。使用这个模型的目标是发现新的方法,将编写分析代码与安装大数据软件结合起来,最好是在一个能够自动测试软件的系统中。

实现DataOps

受到不灵活的系统和低质量数据挑战的组织已经发现了DataOps作为解决方案。DataOps包括促进更快、更可靠的数据分析的工具和过程。虽然没有一个单一的方法来实现一个DataOps程序,一些基本步骤是:

  • 数据民主化:缺乏数据访问/信息是做出更好决策的障碍。业务利益相关者、首席执行官、数据科学家、IT和通用管理人员都应该能够访问组织的数据。自助服务数据访问程序和支持它的基础设施是必不可少的。深度学习和机器学习应用程序需要不断的新数据流来学习和改进。
  • 应用平台和开源工具:DataOps程序中必须包含数据科学平台,以及对框架和语言的支持。用于数据移动、集成、编排和性能的平台也很重要。当开放源码工具可用时,没有必要重新发明轮子。
  • 自动化,自动化,自动化:为了更快地完成数据密集型项目,自动化是绝对必要的。它消除了耗时的手工工作,如数据分析、管道监控和质量保证测试。微服务促进了自给自足,让数据科学家可以自由地以api的形式构建和部署模型。这使得工程师可以根据需要集成代码,而无需重构。总的来说,这会提高生产力。
  • 小心管理:警告:在建立成功蓝图之前(解决工具、流程、优先级、基础设施和数据科学团队需要的关键性能指标),要谨慎地做出影响业务长期发展的决策。
  • 粉碎筒仓:协作是一个成功的DataOps项目的必要条件。数据竖井(除了少数人之外,所有人都无法访问数据)应该被消除。实施DataOps计划所使用的平台和工具应该支持一个更大的目标,即让人们更有效地使用数据。

 

原文:https://www.dataversity.net/understanding-dataops/

本文:http://jiagoushi.pro/node/1223

讨论:请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

SEO Title
Understanding DataOps

DevOps概览

DevOps概览 intelligentx

DevOps

【DevOps】DORA度量和SPACE度量:软件开发领导者的比较综述-BlueOptima

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

软件开发领域引入了许多框架、方法和指标,以优化流程、确保质量并提高整体性能。其中,两组关键指标——DORA和SPACE——分别在衡量DevOps实践和团队能力的有效性方面发挥着关键作用。

DORA指标:衡量DevOps的有效性

DORA(DevOps Research and Assessment)是一个缩写词,代表四个关键指标:部署频率(DF)、变更交付周期(LT)、恢复服务时间(TRS)和变更失败率(CFR)。DORA指标被广泛用于评估DevOps和持续交付实践的性能。

  • 部署频率(Deployment Frequency):此度量标准衡量团队将代码部署到生产环境的频率。频率越高,性能越好,因为这意味着团队可以更快地交付更改和功能。
  • 变更交付周期(Lead Time for Changes):它表示从代码变更开始到交付到生产的时间量。更短的交付周期意味着更快的交付和对业务需求的响应。然而,更快的交付周期与更好的编码输出并不相关。
  • 恢复服务的时间(Time to Restore Service):此指标是指故障或停机后恢复服务所需的时间。时间越短,表示事件响应过程越有效。
  • 更改失败率(Change Failure Rate):它计算导致生产失败的部署的百分比。故障率越低,软件质量越高。

SPACE度量标准:评估团队能力

SPACE是一个新兴的框架,旨在评估软件开发团队的能力。它代表满意度与幸福感、绩效、活动、协作与沟通以及效率与流量。

  • 满意度和幸福感(Satisfaction & Well-Being):考察团队的士气、幸福感和整体幸福感。内容团队通常可以提高参与度和生产力。
  • 绩效(Performance):注重交付工作的质量、可靠性和有效性。高绩效与客户满意度和潜在的更多商机相关。
  • 活动(Activity):监控任务参与度和完成率,以衡量工作量管理和团队效率。
  • 协作与沟通(Collaboration & Communicatio):评估团队在沟通中的协同作用和有效性,这对解决问题和适应能力至关重要。
  • 效率和流程(Efficiency & Flow):评估流程和资源利用的有效性,识别瓶颈并协助战略规划。

对比:DORA与SPACE

乍一看,DORA和SPACE的目标可能相似——优化软件开发团队的性能和效率。然而,仔细观察就会发现,这两个指标服务于组织发展的不同方面,并且在许多方面是互补的。

重点领域

  • DORA:该框架旨在优化DevOps流程。它主要关注与代码部署、服务恢复和更改管理相关的运营效率。DORA提供了一个观察软件开发生命周期的视角,提供了可以指导技术优化的反馈。
  • SPACE:与DORA不同,SPACE旨在优化团队的能力和福祉。它超越了技术流程,还包括团队士气、沟通和整体幸福感等“软”因素。SPACE本质上更以人为本,为团队如何更好地作为人类系统工作提供见解。

最终目标

  • DORA:最终目标是改进技术流程,使其精简、高效和稳健。指标旨在减少瓶颈和故障,从而最大限度地提高开发管道的有效性。
  • 空间:最终目标更广泛——旨在培养一个团队高效、满意、协作良好、资源高效的环境。这确保了更好的生产力、更低的人员流动率和更高的员工满意度。

测量工具

  • DORA:这里的指标通常是定量的,可以通过连续集成/连续部署(CI/CD)工具、事件管理系统以及日志和监控系统自动收集。
  • SPACE:指标更加多样化,包括满意度和幸福感的调查和访谈等定性数据,以及活动的任务完成率或绩效的项目交付时间表等定量数据。

谁受益?

  • DORA:通常,这些指标对直接参与流程优化的技术领导者、DevOps工程师和运营经理最有用。
  • SPACE:这些指标服务于更广泛的受众,包括对团队管理的硬和软方面感兴趣的人力资源专业人员、项目经理和团队领导者。

相互关联性

虽然DORA和SPACE的指标侧重于不同的方面,但它们并不相互排斥。它们可以是高度互补的。例如,一个在“效率和流量”的SPACE指标上得分很高的团队可能会发现更容易改进DORA指标,如“变更交付周期”相反,稳健的DORA指标可以创建一个团队更容易协作和沟通的环境,从而改进SPACE指标。

总之,虽然DORA的目标是开发过程的“如何”,但SPACE的重点是“谁”要使一个组织真正敏捷、有弹性和实用,请同时考虑这两个指标。

指标弱点

DORA指标缺陷:

  • 鼓励速度高于质量:高度关注部署频率和变更交付周期可能会导致以牺牲彻底测试和质量为代价,优先考虑快速发布。
  • 忽略更广泛的开发方面:专注于运营效率,同时可能忽略产品质量、用户满意度和开发团队的福祉。
  • 激励措施不一致的风险:可以激励改善指标的行为,但不一定有助于项目和团队的整体成功或健康。

我们对超过600000名开发人员进行了一项研究,显示了依赖DORA指标时的固有缺陷。你可以在这里找到它。

SPACE框架缺陷:

  • 测量的复杂性:捕捉和量化满意度和沟通等组成部分可能具有挑战性,导致实施和解释困难。
  • 资源密集型:需要大量资源进行持续监控和分析,这可能会成为一些组织的障碍。
  • 有限的适用性:虽然它是全面的,但在所有类型的软件开发项目或团队中可能并不同样有效,这限制了它在特定环境中的有用性。
本文地址
https://architect.pub/dora-metrics-and-space-metrics-comparative-overview-software-development-leaders-blueoptima
SEO Title
DORA Metrics and SPACE Metrics: A Comparative Overview for Software Development Leaders - BlueOptima

【DevOps】DevOps =速度+质量:如何改进DevOps中的测试,从规划到交付

Chinese, Simplified

成功出现在快速上市和优质产品开发的交叉点。如果您率先推出平庸的软件,您的先发优势就会受到影响。

随着DevOps的出现,您可以通过速度质量提供的创新已经从奇迹领域转变为现实的客户期望。如果加速开发没有价值,你的品牌就会受到影响。

考虑这些领域的软件测试改进,以便以DevOps的速度推动高级应用程序的部署。

如何在规划阶段改进DevOps测试


企业需要了解开发,以确保客户能够欣赏应用程序的外观。越早获得可见性,您就能越早解决对您的市场最重要的缺陷,并且您可以更快地部署竞争软件。正确的测试和开发方法可以提供透明度。

测试驱动开发(TDD)是一种标准的开发方法,它使用单元测试在开发人员进行每次更改后查找软件错误,因此他们可以快速修复错误。 TDD在应用程序编码级别拨入故障。企业需要一种方法,可以提供软件行为的透明度,并在软件质量方面大大提高用户的重要性。

行为驱动开发(BDD)是TDD的一个领域,它使用自然语言来确保业务所需的行为在软件内部发展。 BDD在业务利益相关者和开发人员之间建立共享词汇表,以便他们可以就软件变更的适当性进行沟通。使用BDD,DevOps商店可以证明他们正在灌输公司及其客户所需的功能和用户体验。

BDD支持业务在评估应用程序运行状况时的健康状况。 BDD提供业务级别的价值,确认开发正在进行中。

如何在编码阶段改进DevOps测试


企业需要缩短部署时间,同时保持软件质量。开发人员和测试人员之间的反馈循环中的任何延迟都会增加开发时间并设置质量漂移。将测试人员和开发人员聚集在一起可以加强这种循环。

在编码阶段,DevOps组织可以通过将测试人员与程序员配对来提高质量和开发。配对可确保测试人员编写的测试能够反映开发人员当时正在创建的功能。配对在软件准备就绪时通知测试人员,因此他们知道何时运行测试。

通过同步测试和开发,您可以快速提醒程序员,以便他们可以在将代码埋没到更多工作之前修复他们的代码。由此产生的反馈循环构建了动力,因此业务可以迅速启动应用程序。程序员和测试人员对彼此的工作有很多了解,并在他们一起工作时自己进行改进。这些知识使他们能够更好地利用测试和测试结果,并加快反馈循环。

如何在构建阶段改进DevOps测试


减少延迟和加速软件开发的另一个机会出现在构建阶段。在此阶段,测试透明度对于快速修复软件至关重要。

每个可以从测试结果可见性中受益的人都应该拥有它,包括负责创建,测试或修复软件的任何人。为了确保这种透明性,将测试绑定到持续集成(CI)构建过程,该过程构建更新的软件并允许您运行它以检查不完善之处。

将测试连接到CI构建过程有许多好处。当构建测试失败时,系统可以通知团队,以便他们可以快速响应。每次构建测试失败时的广泛沟通对于阻止释放向前发展至关重要,直到您修复有缺陷的功能和构建过程。

修复这些缺陷的关键部分是调整测试以适应下一个构建,以便测试剩余的缺陷。来自系统的警报可确保测试人员及时编写新测试。向开发人员和测试人员发送的系统通知可加快软件构建的通过标记,从而使业务快速进入分发阶段。

DevOps测试的一把伞


毕竟,为了提高质量,我们已经做了很多事情,不要通过有限的测试方法来冲破这个阶段。最好将一系列测试和类别混合在一起,然后充满信心地进行部署,而不是快速进行。

在测试阶段,一些DevOps组织试图通过从流程中删除测试人员并使用单元测试来更快地将版本推向生产。这种方法限制了您可以执行的测试的数量和质量。您可以尽快将软件投入生产,但可能会有更多错误。

如果您有测试人员为良好的覆盖范围定义特定的测试,您仍然可以相对快速地将软件投入生产。测试人员应在您的应用程序上编写并运行完全自动化的烟雾,功能和回归测试,以确保客户满意。

您需要进行冒烟测试以确保应用程序正确启动并访问其子系统。您需要进行功能检查以确保应用程序在各种用例中做出反应。并且您需要进行回归测试以确保之前仍然有效的功能仍然可以正常运行。

这种方法比单元测试更进一步,确定您的应用程序的适用性并确保您的客户对您的产品感到满意。

实现期望


质量和发展相互定义。没有成熟就没有发展,没有质量就没有成熟。没有增长和变化,质量就没有改善,这是随着适当的发展而来的。

由于质量和开发是以这种方式密不可分的,因此击败市场竞争的最佳方法是以DevOps的速度在整个开发生命周期中创新质量。质量可以更快地发展;发展可以达到更高。您需要同时满足或超出客户期望。

旨在帮助改变开发生命周期中剩余测试的QA平台可帮助您实现这些目标。 qTest将测试集成到敏捷和持续交付工作流程中,确保QA流程不断发展以适应新的开发计划。通过将测试集成到开发生命周期中,qTest可帮助组织以更短的周期时间发布高质量的软件。

 

讨论: 请加入只是星球【首席架构师圈】

本文地址
https://architect.pub/devops-speed-quality-how-improve-testing-devops-planning-delivery
SEO Title
DevOps = Speed + Quality: How to Improve Testing in DevOps, from Planning to Delivery

【DevOps】DevOps 工具一览

Chinese, Simplified

为 DevOps 生命周期的每个阶段选择工具。

DevOps 是敏捷方法的下一个演变。将开发和运营团队聚集在一起的文化转变。 DevOps 是一种涉及文化变革、新管理原则和有助于实施最佳实践的技术工具的实践。

当谈到 DevOps 工具链时,组织应该寻找能够改善协作、减少上下文切换、引入自动化以及利用可观察性和监控来更快地交付更好的软件的工具。

DevOps 工具链有两种主要方法:一体机或开放式工具链。一体式 DevOps 解决方案提供了一个通常不与其他第三方工具集成的完整解决方案。可以使用不同的工具针对团队的需求定制开放的工具链。 Atlassian 认为开放式工具链是最好的方法,因为它可以使用同类最佳的工具进行定制,以满足组织的独特需求。使用这种方法通常会提高时间效率并缩短上市时间。

阅读有关 DevOps 工具链的更多信息。

无论组织使用何种类型的 DevOps 工具链,DevOps 流程都需要使用正确的工具来解决 DevOps 生命周期的关键阶段:

  • 计划
  • 建造
  • 持续集成和部署
  • 监视器
  • 操作
  • 持续反馈

借助开放的 DevOps 工具链,所选工具涉及 DevOps 生命周期的多个阶段。以下部分展示了一些最流行的 DevOps 工具,但鉴于市场的性质,此列表经常更改。提供商添加了新功能,使他们能够跨越 DevOps 生命周期的更多阶段,每个季度都会宣布新的集成,在某些情况下,提供商会整合他们的产品以专注于其用户的特定问题。

计划

  • Jira,
  • Confluence ,
  • slack

从敏捷手册中抽出一页,我们推荐允许开发和运营团队将工作分解为更小、更易于管理的块以加快部署的工具。这使您可以更快地向用户学习,并有助于根据反馈优化产品。寻找能够提供 sprint 计划、问题跟踪和允许协作的工具,例如 Jira。

另一个很好的做法是不断收集用户反馈,将其组织成可操作的输入,并为您的开发团队确定这些操作的优先级。寻找鼓励“异步头脑风暴”的工具(如果你愿意的话)。重要的是每个人都可以分享和评论任何东西:想法、策略、目标、要求、路线图和文档。

并且不要忘记集成和功能标志。无论您决定在何处确定功能或项目的范围,都应将其转换为开发积压中的用户故事。功能标志是代码库中的 if 语句,使团队能够打开和关闭功能。

有关此阶段的更多信息,请查看 Atlassian 产品经理关于待办事项梳理和优先级排序的帖子。

建造

生产相同的开发环境:

  • Docker
  • Kubernetes

虽然 Puppet 和 Chef 主要有利于运营,但开发人员使用 Kubernetes 和 Docker 等开源工具来配置单独的开发环境。针对虚拟的、一次性的生产副本进行编码可以帮助您完成更多工作。

当每个团队成员都在相同配置的环境中工作时,“在我的机器上工作!”不再好笑,因为它是真的(现在它只是好笑)。


基础设施即代码:

  • Ansible
  • Chief
  • Docker
  • Puppet
  • Trrraform

开发人员创建模块化应用程序,因为它们更可靠和可维护。那么为什么不将这种想法扩展到 IT 基础架构呢?这可能很难应用于系统,因为它们总是在变化。所以我们通过使用代码来解决这个问题。

基础设施即代码意味着重新配置比修复更快,而且更加一致和可重复。这也意味着您可以使用与生产类似的配置轻松启动开发环境的变体。可以应用和重新应用供应代码以将服务器置于已知基线中。它可以存储在版本控制中。它可以进行测试,并入 CI(持续集成),并经过同行评审。

当机构知识被编入代码时,对运行手册和内部文档的需求就会消失。出现的是可重复的过程和可靠的系统。

源代码控制和协同编码:

  • Github
  • Gitlab
  • Bitbucket

对代码进行源代码控制很重要。源代码控制工具有助于将代码存储在不同的链中,因此您可以通过共享这些更改来查看每个更改并更轻松地进行协作。您可以通过拉取请求完成的同行评审来提高代码质量和吞吐量,而不是在部署到生产之前等待变更批准委员会。

你问什么是拉取请求?拉取请求告诉您的团队您已推送到存储库中开发分支的更改。然后,您的团队可以审查提议的更改并讨论修改,然后再将它们集成到主代码行中。拉取请求提高了软件的质量,从而减少了错误/事件,从而降低了运营成本并加快了开发速度。

源代码控制工具应该与其他工具集成,这允许您连接代码开发和交付的不同部分。这使您可以了解该功能的代码是否在生产中运行。如果发生事件,可以检索代码以阐明事件。

持续集成和交付

 

持续集成:

  • Jenkins 
  • AWS 
  • Bitbucket 
  • CircleCI 
  • Snyk 
  • Sonarsource 


持续集成是每天多次将代码签入共享存储库并每次都对其进行测试的做法。这样,您可以自动及早发现问题,在最容易修复的时候修复它们,并尽早向您的用户推出新功能。

通过拉取请求进行代码审查需要分支并且风靡一时。 DevOps North Star 是一种工作流,它可以产生更少和更快的分支,并在不牺牲开发速度的情况下保持测试的严谨性。

寻找能够自动将您的测试应用到开发分支的工具,并让您选择在分支构建成功时推送到 main。除此之外,您还可以通过简单的集成从团队的实时聊天警报中获得持续的反馈。

了解 Bitbucket Pipelines 如何帮助您将代码从测试到生产自动化。

 

测试:

  • Mabl 
  • Saucelabs 
  • XRay
  • Zep​​hyr 


测试工具涵盖许多需求和功能,包括探索性测试、测试管理和编排。但是,对于 DevOps 工具链来说,自动化是必不可少的功能。从长远来看,自动化测试通过加快您的开发和测试周期而获得回报。在 DevOps 环境中,重要的另一个原因是:意识。

测试自动化可以通过尽早和经常进行来提高软件质量并降低风险。开发团队可以重复执行自动化测试,涵盖 UI 测试、安全扫描或负载测试等多个领域。它们还生成有助于识别风险区域的报告和趋势图。

风险是软件开发中的一个事实,但你无法减轻你无法预料的事情。帮您的运营团队一个忙,让他们和您一起窥探。寻找支持墙板的工具,让参与项目的每个人评论特定的构建或部署结果。工具的额外加分,使操作参与闪电式测试和探索性测试变得容易。

 

部署仪表板:

  • Jira 

发布软件最紧张的部分之一是将即将发布的版本的所有更改、测试和部署信息集中到一个地方。在发布之前,任何人最不需要的就是召开长时间的会议来报告状态。这就是发布仪表板的用武之地。

寻找具有与您的代码存储库和部署工具集成的单个仪表板的工具。在一个地方查找可以让您全面了解分支、构建、拉取请求和部署警告的内容。

 

自动化部署:

  • Bitbucket 
  • Zep​​hyr 


没有适用于每个应用程序和 IT 环境的自动化部署的灵丹妙药。但是使用 Ruby 或 bash 将操作的运行手册转换为 cmd 可执行脚本是一种常见的启动方式。良好的工程实践至关重要。使用变量来分解主机名——为每个环境维护唯一的脚本或代码并不好玩(无论如何都错过了一半)。创建实用方法或脚本以避免重复代码。并同行评审您的脚本以对其进行完整性检查。

首先尝试将部署自动化到最低级别的环境,在那里您将最频繁地使用该自动化,然后将其一直复制到生产。如果不出意外,本练习会突出显示您的环境之间的差异,并生成一个用于标准化它们的任务列表。作为奖励,通过自动化标准化部署可以减少环境内部和环境之间的“服务器漂移”。

 

运营

 

应用程序和服务器性能监控:

  • AppDynamics 
  • DataDog 
  • Slack 
  • Splunk 
  • New Relic 
  • Opsgenie 
  • Pingdom 
  • Nagios 
  • Dynatrace 
  • Hosted Graphite 
  • Sumo Logic 


有两种类型的监控应该自动化:服务器监控和应用程序性能监控。

手动“置顶”一个盒子或测试你的 API 对抽查来说是很好的。但是要了解应用程序(和环境)的趋势和整体健康状况,您需要能够 24/7 全天候监听和记录数据的软件。持续的可观察性是成功的 DevOps 团队的关键能力。

寻找与您的群聊客户端集成的工具,以便警报直接发送到您团队的房间或专门的事件房间。

 

事件、变更和问题跟踪:

  • Jira Service Management 
  • Jira Software 
  • Opsgenie 
  • Statuspage 


解锁 DevOps 团队之间协作的关键是确保他们正在查看相同的工作。报告事件后会发生什么?它们是否与软件问题相关联并可追溯?进行更改时,它们是否与版本相关联?

没有什么比在不同系统中跟踪事件和软件开发项目更能阻碍 Dev 与 Ops 的合作了。寻找将事件、变更、问题和软件项目保存在一个平台上的工具,以便您可以更快地识别和修复问题。

持续反馈

 

  • GetFeedback 
  • Slack 
  • Jira Service Management 
  • Pendo 

客户已经在告诉您您是否构建了正确的东西——您只需要倾听。持续反馈包括定期收集反馈的文化和流程,以及从反馈中获得洞察力的工具。持续的反馈实践包括收集和审查 NPS 数据、流失调查、错误报告、支持票,甚至推文。在 DevOps 文化中,产品团队中的每个人都可以访问用户评论,因为它们有助于指导从发布计划到探索性测试会话的所有内容。

寻找将您的聊天工具与您最喜欢的调查平台集成的应用程序,以获得 NPS 风格的反馈。 Twitter 和/或 Facebook 也可以与聊天功能集成以提供实时反馈。为了更深入地了解来自社交媒体的反馈,值得投资一个可以使用历史数据提取报告的社交媒体管理平台。

分析和整合反馈在短期内可能会减慢开发速度,但从长远来看,它比发布没人想要的新功能更有效。

综上所述...


在 Atlassian,我们相信拥有与开发和运营团队喜欢使用的工具集成的 DevOps 工具链的重要性。这就是我们构建 DevOps 平台以与 171 多家领先的第三方供应商集成的原因,使您能够在所使用的工具中做出最佳决策。因为 DevOps 不应该从单一供应商那里购买,而应该构建。

原文:https://www.atlassian.com/devops/devops-tools

本文:

 

SEO Title
DevOps Tools

【DevOps】网站可靠性工程:DevOps 2.0

Chinese, Simplified

在DevOps中有没有更好的时间?电视节目如“兴趣人物”和“先生机器人“正在越来越好地显示开发人员的实际工作,使用大量的工作代码。像迈克尔·曼(Michael Mann)的“黑帽”(Blackhat)这样的电影(2015)在几个场景中赢得了Google安全团队的DevOps准确性的赞誉。环顾四周,您将发现DevOps文化过滤出来的更广泛的社会元素,如各界人士讨论他们的正常运行时间或快速接近的代码锁。

另一方面,DevOps中最大的棘手也许是开发人员和运营团队通常不会很顺利。开发人员希望在非常紧张的时间表下赶上前期的一些开创性的代码,而运营团队则尽量减缓每个人的下落情况,以发现事故或恶意行为者的系统性风险。两队都希望能够获得更好的用户体验,但到达那里的时候,就会成为一种权力斗争。

将DevOps融合在一起的梦想是对于可以半开半场的人。这种分裂的愿望正是SRE(现场可靠性工程师)的重点。

定义SRE

在介绍SRE这个术语时,Google的工程副总裁Ben Treynor说:

“当您要求软件工程师设计操作功能时,会发生什么。 SRE从根本上做了一些运维团队历来做的工作,但是使用具有软件专业知识的工程师,并且就这些工程师固有地倾向于并且有能力将自动化替代为手动劳动。“

回到2010年,Facebook SRE Mark Schonbach解释了他这样做:

“我是站点可靠性工程师(SRE)的小团队的一部分,这些工作人员日夜工作,以确保您和全球其他4.0亿用户能够访问Facebook,网站加载速度快,所有功能正在... ...我们经常在飞行中擅长工具,帮助我们管理和执行复杂的维护程序,这些程序是世界上最大的,即使不是最大的memcached足迹。我们开发自动化工具来配置新服务器,重新分配现有服务器,以及检测和修复不正常行为的应用程序或服务器。

SREs来自哪里?

可靠性工程是一个从业务世界发展而来的概念,已经有100多年了。第二次世界大战后,IEEE成立了可靠性协会,与电子系统密切相关。十年来,五十九(99.999)成为应用绩效管理的黄金标准。该标准导致创建了一类操作专家,他们知道足够的代码来恢复站点,并将最后的稳定版本尽可能快地重新投入生产。

Treynor解释了在谷歌创造这个新类别的动力,他的典型的幽默幽默:“您通常在操作角色看到的与工程角色相反的一件事是,不仅在责任方面,而且背景和的词汇,最终的尊重。对我来说,这是病态。“

SREs使用哪些工具集?

对于SRE,稳定性和正常运行时间的首要任务。但是,他们应该能够承担起责任,并将自己的方式编入危险之中,而不是添加到开发团队的待办事项列表中。就Google而言,SRE通常是软件工程师,其中有一层网络培训。通常,Google软件工程师必须表现出:

Google自己的Golang和OO语言,如C ++,Python或Java

一种辅助语言,如JavaScript,CSS和HTML,PHP,Ruby,Scheme,Perl等

高级领域,如AI研究,加密,编译器,UX设计等

与其他编码人员联系

除了这些精通之外,Google的SRE必须具备网络工程,Unix系统管理员或更多通用网络/操作技能(如LDAP和DNS)的经验。

SRE的关键作用

艾默生网络能源公司(Emerson Network Power)的一份报告显示,停机时间每小时耗资约30万美元。最明显的影响是流量尖峰下降,电子商务网站在最近的AppDynamics白皮书中被覆盖。然而,Treynor还指出,标准开发商与操作系统的摩擦力如何以其他方式成本高昂。经典的冲突从功能更新发布之前的操作提供给开发人员的支持清单开始。当用户喜欢新开发的功能时,开发者赢得越早越好。同时,在正常运行时间报告中最多有9次操作时,操作胜出。所有变化带来不稳定;你如何调整自己的兴趣?

Treynor的答案是对那些与用户满意度指标有关的人的救济,但并不是那些有心脏病的人。他说,

“100%是基本上所有的错误的可靠性目标。也许起搏器是一个很好的例外!但是,一般来说,对于您可以想到的任何软件服务或系统,100%不是正确的可靠性目标,因为没有用户可以告诉100%可用的系统之间的差异,假设有99.999%的可用性。因为通常情况下,您正在运行的用户和软件服务之间存在许多其他事情,这些边际差异会丢失到其他一切可能出错的噪点上。“

这种反应将焦点从针对用户期望的准确代理的具体正常运行时间指标转移到基于市场现实的可靠性指标。 Treynor解释说,

“如果100%是系统错误的可靠性目标,那么系统的正确的可靠性目标是什么?我建议这是一个产品问题。这不是一个技术问题。考虑到他们支付多少,无论是直接还是间接,以及他们的替代方案,用户都会满意的是什么。

谁雇用SREs?

简单的答案是“每个人”,从软件/硬件巨头如苹果到金融门户如晨星到非营利机构,如劳伦斯伯克利国家实验室。伯克利是一个组织的一个很好的例子,既是能源研究的前沿,同时也保留着一些非常古老的遗留系统。确保几代技术的可靠性是一个巨大的挑战。以下是伯克利实验室负责SREs的工作:

Linux系统管理技能来监控和管理由控制室桥梁负责的系统的可靠性。

开发和维护用于支持NERSC中HPC社区的监控工具,使用C,C ++,Python,Java或Perl等编程语言。

在设计软件,工作流程和流程方面提供改进组监控能力的输入,以确保NERSC和ESnet提供的HPC服务的高可用性。

支持测试和实施新的监控工具,工作流程和新功能,为生产中的系统提供高可用性。

通过管理组件升级和更换(软件,硬盘,卡,电缆等)来协助数据集群的直接硬件支持,以确保节点有效地返回生产服务。

帮助调查和评估新技术和解决方案,推动集团的能力向前发展,超越用户需求,并说服受到激励的员工转型创新,持续改进。

与维基百科的在线公司相比,技能简介,其中SRE任务往往不那么技术性和外交性较强:

提高自动化,工具和流程以支持开发和部署

与工程团队建立深厚的合作伙伴关系,致力于改善用户体验

参加冲刺规划会议,并支持部门间协调

排除站点中断和性能问题,包括通话响应

帮助提供系统和服务,包括配置管理

支持能力规划,现场演示分析和其他分析

帮助一般操作问题,包括机票和其他正在进行的维护任务

在过去一年中,出现了更加战略性的决策层面的转变,反映了客户请求和故障转移程序日益增加的自动化。即使像IBM这样的传统公司,由于物联网议程的推进,SREs也可以使用一些最新的平台。例如,爱尔兰IBM的一个SRE开放课程需要OpenStack Heat,Urban Code Deploy,Chef,Jenkins,ELK,Splunk,Collect D和Graphite等方面的经验。

SREs如何变化

现在的网络世界和现在十年前的SRE进入现场是截然不同的。此后,移动已经重新定义了开发周期,轻松访问基于云的数据中心已将微服务引入主流IT基础架构。 Startups定期使用Rest和JSON作为移动应用程序的首选协议。根据精益创业的原则,DevOps通常是小型,更集中的团队,作为集体SRE。

您会发现开发和运营之间有更多的协作和更少的冲突,只是因为持续的交付模式将开发和运营的责任分解为一个周期。 DevOps这个术语可能会消失,因为两个不同的部门合并在新的世界中,其中UX是一切,更新可能会每周推出。无论在任何给定的SRE工作描述中有多少个9,这个职业生涯路径似乎为您提供最高的工作安全可靠性。

本文:https://jiagoushi.pro/site-reliability-engineering-devops-20

SEO Title
Site Reliability Engineering: DevOps 2.0

【DevOps指标】成功的9个关键DevOps指标

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

祝贺你已经建立了DevOps实践。现在,完成了艰苦的工作,制定了DevOps指标和DevOps KPI,您可以坐下来放松,见证您的Dev和Ops团队之间的合作,因为他们可以更快地交付质量更好的软件。

要是那样容易就好了。

为什么度量在DevOps中很重要?

当我们审视当今的应用程序、微服务和DevOps团队时,我们看到领导者的任务是使用分布在多个位置的系统中的新技术来支持复杂的分布式应用程序。正因为如此,我们衡量和理解关键服务和应用程序的方式也发生了变化。

什么是DevOps指标?

DevOps指标和DevOps KPI对于确保您的DevOps流程、管道和工具达到其预期目标至关重要。与任何IT或业务项目一样,您需要跟踪关键的关键指标。

以下是九个关键的DevOps指标和DevOps KPI,它们将帮助您实现目标。

DevOps的四个主要指标是什么?DORA的四把钥匙

让我们从谷歌DevOps研究与评估(DORA)团队建立的四个最常见的指标开始,即“四个关键”。通过六年的研究,DORA团队确定了这四个关键指标是指DevOps团队的绩效,将他们从“低”排到“精英”,精英团队达到或超过组织绩效目标的可能性是他们的两倍。让我们深入了解这些DevOps KPI如何帮助您的团队更好地执行并交付更好的代码。

1.部署频率(Deployment frequency)

部署频率衡量团队成功发布到生产环境的频率。

随着越来越多的组织采用持续集成/持续交付(CI/CD),团队可以更频繁地发布,通常每天发布多次。高部署频率有助于组织更快地提供错误修复、改进和新功能。这也意味着开发人员可以更快地收到有价值的真实世界反馈,这使他们能够优先考虑最具影响力的修复和新功能。

部署频率衡量长期和短期效率。例如,通过每天或每周测量部署频率,您可以确定团队对流程更改的响应效率。长期跟踪部署频率可以指示您的部署速度是否随着时间的推移而提高。它还可以指示需要解决的任何瓶颈或服务延迟。

2.变更的交付周期( Lead time for changes)

变更的交付周期衡量提交的代码投入生产所需的时间。

此指标对于了解团队对特定应用程序相关问题的响应速度非常重要。交付周期越短通常越好,但交付周期越长并不总是表明存在问题。这可能只是表明一个复杂的项目自然需要更多的时间。变更的交付周期有助于团队了解其流程的有效性。

为了衡量变更的交付周期,您需要捕获提交发生的时间和部署发生的时间。改进这一指标的两个重要方法是在多个开发环境中实施质量保证测试,以及自动化测试和DevOps流程。

3.变更失败率( Change failure rate)

更改失败率衡量在生产中导致需要修复或回滚错误的失败的部署的百分比。

更改失败率着眼于尝试了多少次部署,以及这些部署中有多少在发布到生产中时导致失败。该指标衡量DevOps流程的稳定性和效率。要计算更改失败率,您需要部署的总数,以及将它们链接到由bug、GitHub事件标签、问题管理系统等导致的事件报告的能力。

更改失败率超过40%可能表明测试程序较差,这意味着团队需要进行超出必要的更改,从而降低效率。

衡量变更失败率背后的目标是实现更多DevOps流程的自动化。自动化程度的提高意味着发布的软件更加一致和可靠,更有可能在生产中取得成功。

4.恢复服务的平均时间 (Mean time to restore service)

平均恢复时间(MTTR)服务衡量组织从生产故障中恢复所需的时间。

在一个以99.999%的可用性为标准的世界里,衡量MTTR是确保弹性和稳定性的关键做法。在发生计划外停机或服务降级的情况下,MTTR可帮助团队了解哪些响应过程需要改进。要测量MTTR,您需要知道事件何时发生以及何时得到有效解决。为了更清楚地了解情况,了解是什么部署解决了事件,并分析用户体验数据以了解服务是否已有效恢复也很有帮助。

对于大多数系统,最佳MTTR可能小于一小时,而其他系统的MTTR小于一天。任何超过一天的时间都可能表明警报或监控不力,并可能导致更多受影响的系统。

为了实现快速MTTR指标,以小增量部署软件以降低风险,并部署自动化监控解决方案以预防故障。

五个补充DevOps KPI

DORA的“四个关键”为提高开发实践的性能奠定了良好的基础,但它们只是一个开始。以下是另外五个DevOps KPI,可帮助您的团队实现更优化的绩效。

5.缺陷逃逸率(Defect escape rate)

缺陷逃逸速度衡量“逃逸”测试并发布到生产中的bug数量。

此指标可帮助您确定测试过程的有效性和软件的总体质量。高的缺陷逃逸率表示过程需要改进和更多的自动化,而较低的比率(优选接近零)表示功能良好的测试程序和高质量的软件。

为了获得该度量的可见性,您需要跟踪在发布的代码和软件中发现的所有缺陷。这意味着要查看开发/QA和生产中的缺陷,以便深入了解从开发和QA进入生产的任何缺陷。通常,组织应该努力在发布进入生产之前找到QA中90%的缺陷。

6.平均检测时间(Mean time to detect)

平均检测时间(MTTD)衡量事件开始到发现之间的平均时间。

在其他DevOps度量中,此度量有助于确定您的监控和检测能力在支持系统可靠性和可用性方面的有效性。衡量MTTD受其他DevOps KPI指标的影响,包括平均故障时间(MTTF)和平均恢复时间(MTTR)。要计算MTTD,请将给定团队或项目的所有事件检测时间相加,然后除以事件总数。

MTTD面临的挑战是准确了解IT事件何时开始,这需要分析和评估历史基础设施KPI数据的能力。

7.自动化测试覆盖的代码百分比(Percentage of code covered by automated tests)

自动化测试覆盖的代码百分比衡量接受自动化测试的代码的比例。

自动化测试通常表明代码更稳定,尽管手动测试仍然可以在软件开发中发挥作用。自动化测试覆盖更高比例的代码是我们的目标,尽管总是有一些失败的测试是健康的——重要的是团队编写代码以按预期工作,而不仅仅是通过测试。

8.应用程序可用性(App availability)

应用程序可用性衡量应用程序完全运行和可访问以满足最终用户需求的时间比例。

高可用性系统旨在满足“五个9”(99.999%)这一黄金标准KPI。要准确衡量应用程序可用性,首先要确保您能够准确衡量真正的最终用户体验,而不仅仅是网络统计数据。虽然团队并不总是期望停机,但他们通常会因为维护而计划停机。计划内停机使DevOps和SRE团队成员之间的沟通对于解决不可预见的故障和确保前端和后端无缝运行至关重要。

9.应用程序使用和流量(Application usage and traffic)

应用程序使用情况和流量监控访问系统的用户数量,并通知许多其他指标,包括系统正常运行时间。

一旦您部署了软件,您就会想知道有多少用户正在访问您的系统,以及发生的事务数量,以确保一切正常运行。

例如,如果应用程序的流量和使用量过多,它可能会在压力下失败。同样,这些指标对于新部署和现有部署的间接反馈也很有用。如果使用量和/或流量下降,这可能是反馈,表明您所做的更改没有得到最终用户的好评。

拥有DevOps KPI(如这些应用程序使用情况和流量指标)可以让您查看是否有问题,以及何时出现流量异常峰值或其他异常使用或流量指标。同样,您可以针对专门支持关键应用程序的微服务来监控使用情况和流量。因此,您的DevOps团队可以使用这些指标来确保系统正常运行,并采取适当的行动,例如,恢复到以前的版本以使最终用户满意。

如何监控云资源和分布式系统的DevOps指标和KPI

一个成功的DevOps实践需要团队监控一组一致且有意义的DevOpsKPI,以确保流程、管道和工具满足更快交付更好软件的预期目标。

为了帮助团队了解DevOps工具和流程,Dynatrace为多云环境提供了自动的全栈可观察性。Dynatrace DevOps解决方案以人工智能为核心,从开发到生产,自动理解整个DevOps生命周期的数据。这种提供精确答案并与500多种技术集成的能力使团队能够定制和微调DevOps指标,自动化更多DevOps流程,并提高效率以获得卓越的用户体验。

 

本文地址
https://architect.pub/9-key-devops-metrics-success?check_logged_in=1
SEO Title
9 key DevOps metrics for success

【DevOps指标】衡量成功的17个DevOps指标

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

软件开发中的生产力一直很难衡量。与其他行业不同,编程行为并不容易并行化。开发过程的独特之处在于,它需要技术和沟通技能的多样化组合,这需要一套专门的DevOps指标来跟踪团队的生命体征。

软件开发的脉搏

并非所有指标都是平等的。根据上下文的不同,有些比其他更有用。我们选择衡量的东西可以帮助我们发现问题,或者在无关数据和非生产性目标背后掩盖问题。

在决定跟踪哪些DevOps指标时,我们应该考虑以下几点:

  • 当人们感到被观察时,他们的行为就不一样了。这被称为霍桑效应,它会产生过度的压力。最好尽可能保持指标的非个人性和匿名性
  • 第一点还意味着,指标只能用于跟踪团队随时间的进展,而不能用于比较团队或个人。
  • 过多地强调达到任意数字会产生与系统博弈的动机。Dave Farley和Jez Humble在这个问题上有这样的看法:

“测量代码行,开发人员将编写许多短代码行。测量修复的缺陷数量,测试人员将记录可以通过与开发人员快速讨论修复的错误。”

--持续交付:通过构建、测试和部署自动化实现可靠的软件发布

因此,在选择要用于跟踪团队进度的指标之前,每个人都应该知道,他们的唯一目的是跟踪进度并识别问题。它们不是为了表扬或惩罚个人。

A metric dashboard showing the project score and health.

A dashboard with all the chosen DevOps metrics should be created, and it should be visible to everyone on the team.

四个DORA指标

DORA度量是我们衡量软件开发的主要工具。它们包括四个基准:

  • 部署频率(DF):组织向用户成功发布产品或将其部署到生产中的频率。
  • 变更交付周期(LT):承诺达到生产或发布所需的时间。
  • 平均恢复服务时间(MTTR):组织从生产故障中恢复所需的时间。
  • 变更失败率(CFR):导致生产失败的发布或部署的百分比。

开发团队可以分为四个级别之一:低、中、高和精英。

Metric Low Medium High Elite
DF fewer than 1 per 6 months 1 per month to 1 per 6 months 1 per week to 1 per month On demand (multiple deploys per day)
LT more than 6 months 1 month to 6 months 1 day to 1 week Less than 1 hour
MTTR more than 6 months 1 day to 1 week Less than a day Less than 1 hour
CFR 16 to 30% 16 to 30% 16 to 30% 0 to 15%

年复一年,DORA研究团队已经证明,高DORA分数是高绩效的可预测指标。因此,它们应该包含在任何涉及软件开发的度量策略中。

循环时间(Cycle time)

与DORA一样,循环时间也是生产力的另一个主要指标。它被定义为从我们决定添加功能到将其部署或发布给公众或客户之间的平均时间。

The stages of development. From left to right: feature approved, feature design, coding, deployment. The cycle time spans all these. While the lead time to changes spans from coding to deployment.

Cycle time spans the entirety of feature development; from inception to reality. Lead time to changes begins ticking when the first line of code for a feature is committed.

快速的周期时间意味着团队能够以持续的速度始终如一地提供功能。

质量(Quality)

质量对不同的人意味着不同的东西。虽然一些团队强调遵守风格规则,但其他团队可能更关心安全风险或保持愉快的用户体验。重要的是,团队就他们的素质达成了一致。

我们可以使用混合参数来估计代码的质量。不满足预定质量条的情况应该导致CI管道失败。一些有价值的指标包括:

  • 漏洞数量。
  • 违反风格准则。
  • 代码覆盖范围。
  • 陈旧分支的数量。
  • 循环复杂性。
  • 破坏的架构约束。例如,确保一个模块中的代码不引用另一个模块的类。

客户反馈

客户的反馈可以有多种形式,例如打开的门票、使用模式、社交媒体上的提及,以及从净促销分数(NPS)调查中收集的信息。具体情况因业务和产品而异,但我们必须以某种具体形式代表客户的声音,因为归根结底,他们会买单。

A short NPS survey asking for feedback.

员工满意度

我们必须关注的不仅仅是我们的用户和客户。开发人员、测试人员、质量和业务分析师、产品经理和经理也至关重要,因为我们需要他们来制造一个伟大的产品。最好的想法来自乐观、自信和休息良好的头脑。

员工满意度受到多种因素的影响,我们应该以某种方式衡量这些因素:

  • 文件的全面性和更新程度如何?
  • 加入一个新的开发人员有多容易?
  • 员工是否觉得自己的声音被听到了?
  • 工作/生活的平衡如何?有人精疲力竭吗?
  • 工作场所是一个安全的环境,可以冒险和试验吗?
  • 员工是否有正确的工具来完成他们的工作?
  • 他们觉得自己可以安全地提出建设性的批评吗?

平均CI持续时间

软件开发是一种实验性的练习——我们做一些小的改变,看看它们是如何运作的。来自CI流水线的反馈最终确定了改变是否停留在代码库中。

当CI/CD过程缓慢时,以小增量工作会变得痛苦,因为开发人员要么等待看到结果,要么继续前进,并试图记住在结果出来时返回管道。无论哪种情况,都很难保持创意流。

CI duration is equal to total CI runtime divided by total CI runs.

CI管道的平均持续时间应以分钟为单位。我们的目标应该是不到10分钟,以保持开发人员的参与和代码的流动。如果你的管道太长,请查看Semaphore的测试优化指南。

CI每天运行次数

这是每天执行CI管道的次数。我们希望将这个数字保持在较高水平——每个活跃的开发人员至少运行4或5次——因为这意味着开发人员信任并依赖CI/CD过程。

当每天运行的CI减少时,可能是由于CI/CD系统使用缓慢或不方便造成的。

CI平均恢复时间(MTTR)

当构建不起作用时,我们无法进行测试、发布或部署。在这种情况下,每个人都应该停止他们正在做的事情,专注于恢复构建。平均恢复时间衡量一个团队修复损坏的CI构建平均需要多长时间。在衡量这个指标时,我们通常只关注主分支。

较长的恢复时间表明,我们需要努力使CI/CD过程更加稳健。我们还必须确保优先修复CI构建的习惯在团队文化中根深蒂固。

CI测试失败率

衡量CI管道因测试失败而失败的频率。测试是一个安全网,所以失败没有错。尽管如此,开发人员在提交代码之前应该在他们的机器上运行测试。如果失败率太高,这可能表明开发人员发现很难在本地运行测试。

CI test failure rate is equal to test failed divided by total tests executed.

CI test failure rate formula

CI成功率

CI成功率是成功的CI运行次数除以总运行次数。成功率低表明CI/CD过程很脆弱,需要更多的维护,或者开发人员过于频繁地合并未经测试的代码。

CI success rate is equal to successful CI run divided by all runs.

CI success rate

片状(Flakiness)

片状表示CI管道有多脆弱。片状构建在没有明显原因的情况下随机失败或成功。片状是由片状测试或不可靠的CI/CD平台引起的。缺陷测试会对CI运行时间、成功率和恢复时间产生负面影响。

The Semaphore test summary screen.

The Test Summary tab shows flaky and slow tests.

覆盖范围

代码覆盖率是测试套件覆盖的代码的百分比。这有点争议,因为众所周知,这是一个经常被滥用的指标。例如,要求100%的覆盖率并不能提高质量,相反,它会导致对琐碎代码进行不必要的测试。

和其他任何东西一样,适度使用覆盖率是有用的。例如,一个覆盖率为5%的项目无疑是测试不足,以至于测试结果没有向我们展示太多。

缺陷逃逸率

测量CI/CD进程未检测到的错误数。高值意味着测试不充分。在这种情况下,我们应该检查覆盖率值,然后重新评估测试套件的结构。我们的测试套件中可能需要更多类型的测试。

Defect Escape Ratio is equal to errors found in production divided by all errors found.

Defect Escape Ratio

正常运行时间

Uptime是应用程序可用时间的百分比。它越高,特定时期内的停机次数就越少。例如,99.9%的正常运行时间相当于每年8小时45分钟的停机时间。这个运营DevOps指标应该始终是我们衡量标准的一部分,因为每次站点或应用程序停机时,我们都有失去客户的风险。

正常运行时间值低表明基础结构、代码和/或部署过程中存在问题。

Uptime Total Yearly Downtime
99.9 % 8h 45m 56s
99.99 % 52m 35s
99.999 % 5m 15s
99.9999 % 31s

服务水平指示器

签署服务级别协议(SLA)的企业必须注意正常运行时间,以避免罚款或其他处罚。服务级别指示器(SLI)将实际应用程序性能或正常运行时间与预定标准进行对比。

即使SLA没有生效,公司也可以建立内部服务水平目标(SLO),以实现相同的功能。

A graph showing the SLI as time goes by. The line crosses below the SLA line at some point, triggering some penalties.

SLI shows reality versus SLA or SLO.

平均检测时间(Mean time to detection)

这是在发现问题并将其分配给相应团队之前,问题在生产中持续存在的平均时间。我们可以将其衡量为从问题开始到提出问题或罚单的时间。平均检测时间与监控的全面程度和通知的有效性直接相关。

Time to detection is the time it takes a team to take action from the point a component failed.

平均无故障时间(Mean time between failures)

衡量系统或子系统的平均故障频率。这是一个适用于衡量应用程序子组件稳定性的指标。它可以帮助我们确定哪些部分需要重构。

The application is modified as time goes by. On the left, the application is missing a feature. Then, the feature is added and works. Finally, the feature breaks. The time between feature is added, and it breaks is the time between failures.

Time between failures.

Devops指标只是衡量症状

指标是项目的重要标志。一个糟糕的指标是一种症状,而不是疾病。他们指出了问题的存在,但没有明确说明根本原因。虽然通过“管理”指标下的变量来解决问题可能很诱人,但这样做类似于自我治疗——它只会成功地隐藏症状。像任何一位好医生一样,一位好的工程师会进行调查,提出解决方案,并通过检查指标是否有所改进来确认其有效性。

本文地址
https://architect.pub/17-devops-metrics-measure-success
SEO Title
17 DevOps Metrics To Measure Success

【DevOps效能】使用DORA指标成为精英团队

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

几十年来,各组织一直在尝试衡量软件开发生产力。注意力往往集中在易于量化的指标上,如工时、提交的代码行、功能点或每次冲刺添加的功能。遗憾的是,这些都不足以预测团队生产力。这是一个如此复杂的问题,以至于有些人宣称它不可能解决。

尽管这些尝试都失败了,DORA还是着手制定发展生产力的衡量标准。

什么是DORA?

DORA(DevOps研究与评估)是一个由Nicole Forsgren、Jez Humble和Gene Kim于2015年成立的研究团队。该小组的目标是找到改进软件开发的方法。在七年的时间里,他们调查了数百个不同行业组织的数千名软件专业人员。

该团队的发现首次发表在《加速:精益软件和DevOps的科学》(2018)上。该书介绍了与高绩效组织相关的四个基准:DORA指标。

在上述书籍出版的同一年,谷歌收购了该集团,并成立了DORA研究项目,负责发布年度DevOps状态报告。

DORA指标是什么?

DORA的研究获得了突破性的见解,即在足够长的时间内,速度和质量之间没有权衡。换句话说,从长远来看,降低质量并不能带来更快的开发周期。

速度和稳定性都至关重要。以牺牲质量为代价来增加功能会导致不合格的代码、不稳定的发布和技术债务,最终扼杀进展。

DORA确定了软件开发的两个关键方面:

  • 吞吐量:衡量新代码达到生产所需的时间。
  • 稳定性:衡量部署失败的频率和修复的平均时间。

DORA用两个指标衡量稳定性:

  • 恢复服务的时间(MTTR):组织(平均)从生产故障中恢复所需的时间。
  • 变更失败率(CFR):导致生产失败的发布或部署的百分比。

在吞吐量方面,DORA又增加了两个指标:

  • 部署频率(DF):组织向用户成功发布产品或将其部署到生产中的频率。
  • 变更交付周期(LT):承诺达到生产或发布所需的时间。

On the stability side, we have the metrics: time to restore service and change fail rate. On the Throughput column: deployment frequency and lead time to changes.

DORA衡量软件开发的两个方面:稳定性和吞吐量。

DORA指标采用以下4个级别进行测量:精英、高级、中级和低级。

Metric Low Medium High Elite
部署频率 fewer than 1 per 6 months 1 per month to 1 per 6 months 1 per week to 1 per month On demand (multiple deploys per day)
变更的交付周期 more than 6 months 1 month to 6 months 1 day to 1 week Less than 1 hour
恢复服务的时间 more than 6 months 1 day to 1 week Less than a day Less than 1 hour
更改失败率 16 to 30% 16 to 30% 16 to 30% 0 to 15%

DORA水平

⚠️ 在《2022年DevOps状态报告》中,精英和高级被合并为一个层次。

根据《2021年DevOps状况报告》(PDF),不同级别的表现是惊人的。

Compared to low performers, elite teams have 973 more code deployments, are 6570 times faster at landing changes in production, are 6570 times faster to recover from incidents, and experience 3 times fewer change failures.

💡 2021年,DORA团队引入了第五个指标:可靠性,通过评级组织如何达到或超过其可靠性目标来衡量运营绩效。

通过DORA指标达到精英水平

让我在本节的开头提出一些警告:

  • DORA指标仅在跟踪团队在DevOps旅程中的进展时有效。它们不能用于比较团队或个人。
  • 不应混淆目标和指标。由于所有指标都可以博弈,将指标等同于目标会导致不正当的激励。例如,如果管理层决定无论成本如何都要优化部署频率,那么部署他们能想到的任何微小更改都将符合团队的最大利益,无论它是否会为用户增加价值。
  • 组织文化对团队绩效有着巨大的影响。我们稍后会在帖子中再次讨论这个问题。

好了,既然已经解决了,让我们继续吧。

在过去的几年里,精英球队的数量一直在增长。2018年,只有7%的团队或组织被视为精英。2021年,这一数字增长到26%。所以我们知道增长是可以实现的。

There are more elite teams. In 2018 only 7% of teams were elite, 48% high, 37% medium, and 15% low. In 2021, elite teams made up 26%, high were at 40%, medium were at 28%, and low were at 7%.

DevOps maturation of the software industry measured in DORA metrics. Source: State of DevOps Report 2021.

问题是如何使用DORA指标来提升团队或组织的比赛水平。度量中的错误值是一种症状。它表明存在组织、文化或技能问题需要解决。一旦对这些进行了管理,基本指标自然会得到改进。

提高吞吐量

生产周期较慢的组织部署频率较低,更改的交付周期较长。通常,我们可以通过优化连续集成和连续交付(CI/CD)、识别组织问题、加快测试套件以及减少部署摩擦来提高吞吐量。

问问自己,“是什么阻止我现在发布?”答案将揭示组织中的瓶颈。例如,您可能在代码评审上浪费了太多时间,等待QA批准更改,或者在其他团队完成其功能之前等待发布。

您可以通过多种方式提高吞吐量:

  • 减小发布的大小。经常进行小型、安全的更换。如果某个功能还没有准备好进入黄金时段,请将其隐藏在功能标志后面或通过暗启动进行发布。
  • 确保整个部署过程是自动化的,只需按下一个按钮即可完成。这意味着在部署过程中没有检查表,也没有人工干预。
  • 采用基于主干的开发。它将减少合并冲突的机会,并鼓励合作。
  • 通过管理缓慢的测试和删除零散的测试来优化持续集成的速度。
  • 跟踪您在软件交付过程中的每个步骤上花费的时间。检查循环时间,找出可以节省时间的地方。

提高项目的稳定性

没有稳定性的速度最终会导致累积的技术债务,并花费更多的时间来修复错误,而不是发布功能。当稳定性指标看起来不好时,用户会有糟糕的体验,开发人员会把大部分时间花在灭火上,而不是编码上。

以下是一些可以用来提高稳定性的想法:

  • 在CI管道中执行代码质量检查。拒绝发送不符合标准的代码。
  • 加强代码同行评审过程,或尝试配对编程。
  • 当灾难发生时,把重点放在恢复上,而不是所有其他任务上。
  • 确保您的系统中有足够的监控和可观察性,以快速确定故障的原因。
  • 每次发生严重停机时,都要召开“经验教训”会议。
  • 在部署管道中使用烟雾测试,以避免在故障环境中部署。
  • 实现部署的自动回滚。尝试金丝雀或蓝绿色部署。

生成性文化

也许不足为奇的是,《2021年DevOps现状》报告发现,精英团队与组织内的生成文化之间存在高度相关性。“生成文化”一词是由Ron Westrum创造的,用来描述一种包容、高度合作的文化,它提供了在不担心后果的情况下冒险所需的心理安全。

组织的文化超越了一个团队。它必须得到管理层的支持,由工程团队共享,并在整个公司进行维护。一种生成性的文化可以减少孤立,鼓励工程团队以外的合作。

不理智的

(以动力为导向)

官僚的

(以规则为导向)

生成

(以效能为导向)

Low cooperation Modest cooperation High cooperation
Messengers “shot” Messengers neglected Messengers trained
Responsibilities shirked Narrow responsibilities Risks are shared
Bridging discouraged Bridging tolerated Bridging encouraged
Failure leads to scapegoating Failure leads to justice Failure leads to inquiry
Novelty crushed Novelty leads to problems Novelty implemented

资料来源:组织文化类型学,Ron Westrum博士,2004年。

结论

认为改进DORA指标会自动产生更好的团队是错误的。恰恰相反:一种包容、生成的文化自然会产生更高的基准。换言之,在低合作、规避风险的环境中,没有机会维持一支精英团队。将指标设定为目标不仅目光短浅,而且往往是一个组织误入病态或官僚文化的指标。

你想知道你的DORA分数是多少吗?进行DevOps快速检查并找出答案!

本文地址
https://semaphoreci.com/blog/dora-metrics
SEO Title
Become an Elite Team With Dora Metrics

【SRE】什么是站点可靠性工程?

Chinese, Simplified

工程领导者的入门读物


站点可靠性工程 (SRE) 是将 IT 运营职责与软件开发相结合的结果。对于 SRE,有责任满足为他们管理的服务设定的服务水平目标 (SLO) 和我们在合同中承诺的服务水平协议 (SLA)。

SLO 设定了可靠性目标,通常称为错误预算。在系统运行时收集数据,并将其编译为服务级别指标 (SLI),以帮助指导 SRE 做出关于系统哪些部分需要优先增强的决策。为了帮助解决这个问题,工程师可以自动化任何事情,而不是重复任务。这种自动化通过消除工作来创造更多的工程师时间,这些时间可以花在使站点越来越可靠上。

对可靠性的关注是区分 DevOps 和站点可靠性工程的主要因素,而不是自动化。

对可靠性的关注是区分 DevOps 和站点可靠性工程的主要因素,而不是自动化。在 SRE 团队中,工程师承担责任,即构建软件的人也将其交付并在生产中拥有它。从这个意义上说,SRE 有时被称为 DevOps 的下一阶段。

将这种自动化期望应用到操作任务中,使成为站点可靠性工程师的软件开发人员和系统管理员的任务是学习如何处理可能超出他们以前经验的复杂问题。现在,人们期望他们处理延迟、性能、高可用性 (HA)、复杂的分布式生产系统、系统监控、应急响应和灾难恢复等问题,甚至只需要绝对必要的人工交互即可进行变更管理。这导致越来越高的效率。

SRE 团队是软件开发、系统管理和 IT 运营全部合并在一起的。作为系统管理员、开发人员或 dba,任何给定成员都可能是最强的,但没有成员只做一件事。他们都朝着一个共同的目标共同努力,没有传统的墙壁阻碍沟通和节奏。

本文:

现场可靠性工程的基础和好处是什么?


站点可靠性工程的基本原理很容易解释,但需要一些工作才能应用。我们从基本理解开始,即当今的计算机系统和平台具有前所未有的固有复杂性。

我们的系统很复杂


我们架构中的移动部件和离散的功能单元的数量是巨大的,任何一个人都不可能在任何特定时刻完全理解。此外,我们的系统在不断变化。正在增加新的容量。故障转移系统。负载均衡。金丝雀部署。不再需要的旧容器不断被移除。

过去我们在纸上设计系统,绘制系统图和系统架构,而今天我们的系统在墨迹未干之前就已经发生了变化,任何尝试都这样做了。它们充其量只能被认为是近似值。

自动化帮助我们管理复杂性


如今,大型系统的大部分管理都涉及平凡的重复性任务。由于营销部门发送了一封特殊的机会销售电子邮件后,大量在线购物者涌入我们的网站,我们的负载增加了?提升容量?因为报税季结束了,每个按时报税的人都已经完成并且已经收到了他们的结果,所以负担已经减轻了?删除不需要的冗余应用程序服务器。

没有工程师愿意一遍又一遍地做同样的事情。重复很快就会变得乏味,并导致寻找新的有趣挑战的工作。我们喜欢解决问题并提出有用的解决方案。我们更喜欢它,因为它可以让我们摆脱不喜欢的任务,让我们有更多的时间去做有趣和有益的工作。

当自动化可靠并且使我们的系统对高影响事件更具弹性时,我们更喜欢自动化。当我们不必扑灭由比典型数量更多的并发用户引起的隐喻火灾时,我们都非常感激。当我们的系统在这成为问题之前进行监控、警报甚至做出反应时,每个人都会受益。

谁从现场可靠性工程师那里受益?


任何大到需要超过少数人来管理其系统的公司都将从站点可靠性工程中受益。任何拥有足够大或足够重要以要求 99% 或更高可用性的系统的人都会受益。如果正常运行时间很重要,那么实施良好的 SRE 将帮助您改进它。

最大的好处来自拥有大量用户的公司,无论是公司内部还是外部客户。此外,处理大量数据或工作负载从资源繁重到轻量化的公司。

在这些情况下,许多公司正在将其大部分处理和计算能力转移到基于云的服务上。有些人已将所有内容都移至云端,而另一些人则有理由使用混合架构,将个人身份信息 (PII) 或公司财务等敏感数据保留在内部,同时将其他处理移至云端。还有一些人拥有使用虚拟化或内部云的内部拥有的数据中心。

站点可靠性工程师每天都做什么?


站点可靠性工程师首先查看系统,然后执行最简单和最平凡的任务并将它们自动化。这可以腾出更多时间来编写新功能并为潜在问题做准备。

站点可靠性工程师往往来自软件开发背景或系统或运营背景。我们所有人都花时间完成这些任务:编写代码和管理系统。这就是为什么我们既适合知道什么对自动化有用,也适合编写执行自动化的代码。

减灾


在处理最简单的容易实现的任务的同时,我们还研究了减灾和准备计划,并编写了运行手册,计划在坏事发生时如何处理坏事。

高级和初级 SRE 都值得一起尝试尽可能多地自动化已发现的缓解任务:当响应时间很慢时启动额外的数据库服务器,当 CPU 使用率或网络容量变得有点过时时重新路由过载的应用程序服务器周围的流量接近容量,等等。

配置和使用可观察性监控


所有这些都需要良好的监控,以实现对系统的可观察性以及组件是否按预期运行。猜猜谁负责这件事?是的,SRE。监控需要了解系统以及哪些数据是有意义和有用的。它还需要良好的工具并花时间学习如何很好地使用它。

我们可以监控“一切”,但这样做的结果是大量信息,这些信息势不可挡,很快就会被忽视。相反,我们会花时间深思熟虑地考虑哪些指标告诉我们我们需要了解系统的哪些信息,最好在影响用户的问题发生之前以及在停机时间发生之前很久。

我们无法捕捉到所有东西,但科学地这样做可以帮助我们捕捉到我们知道需要捕捉的尽可能多的东西,同时防止我们因过多的噪音和分心而受到干扰。

网站和软件维护


为了安全和最新,必须维护一个系统。当您以质量、稳定性和安全性为目标时,不能接受过时的软件版本或旧配置。

SRE 会花费一些时间来确保及时正确更新软件。他们可能会自动执行诸如版本检查、安全证书等到期日期和依赖需求之类的事情。

事故管理和事故修复


它就在名称中,“站点可靠性”。 SRE 的主要任务之一是保持站点正常运行,当站点因出现故障而停止运行时,尽快使其恢复正常运行。

发生了一个事件。发出警报。寻呼机职责。随叫随到的 SRE 停止了她正在做的任何事情,并开始努力找出问题所在。待命团队中的每个人都聚集在一起,可能是亲自聚会,也可能是通过视频或音频电话会议。信息被收集和共享。事件手册和运行手册被提取出来,用于确定要查看的内容的优先级,并尝试让事情再次正常运行。如果他们无法提供帮助(有时会发生这种情况),则会讨论想法和潜在的修复方法。职责分散在团队成员之间。每个人都齐心协力进行任何研究和任务,以使系统备份、运行和可用。

有几个指标可用于衡量事件响应的速度和效率,例如:

  • 平均检测时间 (MTTD),测量发现问题所需的平均时间
  • 平均解决时间 (MTTR),衡量修复故障系统所需的时间
  • 平均无故障时间 (MTTF),即有缺陷的系统在出现故障之前可以继续运行的平均时间;这类似于正常运行时间,可帮助团队在系统组件停止工作之前计划未来更换系统组件
  • 平均故障间隔时间 (MTBF),用于衡量系统或组件正常工作的平均时间

防止数据丢失


SRE 最著名且看似显而易见的工作是维护系统可用性。也许不那么明显,但更重要的是保持我们数据的完整性。耐用性。防止数据丢失。

数据是我们系统中最重要的东西。每个组件的存在都是为了处理数据或为数据做某事。输入(接收)数据、存储数据、处理数据、转换数据、使用数据、输出数据,不胜枚举。

有些数据是专有的。有些是敏感的。许多类型的数据只能根据严格的监管标准进行处理。

没有好的数据,我们的系统就没有价值。如果我们的数据没有得到适当的保护而被盗,我们可能会被罚款、被起诉,甚至破产,而委托我们的客户会以我们必须努力防止的方式变得脆弱。

如果我们的数据存储损坏或数据库崩溃,我们最好希望我们有良好的备份系统和内置冗余。SRE 也对此负责,这是另一个需要好的工具和知道如何使用它的地方。

防止过去的问题再次发生


SRE 会查看过去的问题事件并尝试防止它们再次发生。这就是诸如无责回顾之类的活动非常有价值的地方。逐个问题地讨论一个问题,注意发生了什么以及如何发生的,而不让任何人成为替罪羊,这将引发有用的想法和参与,以防止问题再次发生。

有趣的部分是当我们开始自动化缓解并使用一点混沌工程对其进行测试以向自己证明我们实际上已经预防了未来的灾难。

事件分析


这些术语可以以两种方式使用。我们可以分析正在进行的事件,寻找如何修复和恢复。这包含在事故维修中。在这里,我们正在考虑另一种分析,即在解决问题并且一切恢复正常之后发生的分析。

有些地方将信息收集和呈现过程称为事后分析。我们更愿意称其为回顾展。无论名称如何,SRE 文化都坚持以无可指责的方式完成。我们不是在寻找替罪羊,而是在学习。这不是关于谁犯了错误(即使事件是由人为错误引起的),因为人为错误通常是因为有人做了他们不应该被工具或​​软件允许做的事情。

有关事件的每个可用细节都收集在一起,按逻辑(通常是时间顺序)顺序组装,并由团队呈现。我们分享是为了学习。

有时,回顾会在整个公司或至少在受影响的业务部门之间共享。有时,它甚至被公开分享。在这些情况下,还包括有关如何解决问题以及如何减轻或防止再次发生问题的信息。

学习和分享技能


站点可靠性工程的很大一部分是透视。 SRE 团队致力于互惠互利;以让尽可能多的人受益的方式共享信息。得到这份工作并不是学习的结束。作为成熟和成功的 SRE 团队的一部分,了解系统并对其进行良好管理并不是最后阶段。这种相互尊重、分享、团队合作以及专注于共同构建更美好的未来系统而不是担心上次“谁打破它”的理念是关键。

高级 SRE 会花时间使用专门编写的入职手册来教授初级 SRE,这些手册通过指导和积极交流最佳实践和机构知识来编写他们需要学习的主要任务。做好站点可靠性工程绝对需要在每个团队内部和跨团队发展一个社区。这里的失败最终将导致实践的失败。

具有演讲天赋的工程师通常会在会议和其他活动中找到分享他们知识的机会,通常由其他 SRE 和 DevOps 从业者以及想要了解更多实践的人参加。这为学习新技能、了解新技术以及交叉授粉和混合跨公司工作的实践提供了绝佳机会。最喜欢分享的一件事是停电故事。 SRE 有一种讲故事的能力,可以以一种引人入胜的方式传达有意义的信息。

此外,还有很多机会可以在网上找到其他从业者。许多人为公司或在他们的个人网站上写博客文章来分享他们正在学习的东西。我们在 Twitter、Meetup 组、Reddit、一些 LinkedIn 社区组和专门的 Slack 主题频道(透明时刻……最后一个链接指向 Gremlin 赞助的 Chaos Engineering Slack,它有来自整个行业的参与者很好)超越格雷姆林)。

站点可靠性工程是如何开始的?


历史可以追溯到 2000 年代初,早于市场较好的术语 DevOps。 “站点可靠性工程师”这个头衔是由 Google 的工程副总裁 Ben Treynor 发明的,他最终负责成千上万的软件工程师。他的LinkedIn个人资料说,

如果 Google 停止工作,那是我的错。

亚马逊和 Netflix 等其他公司也在类似的时间开始了类似的活动。他们所有人都在寻找方法,使他们已经大规模的部署更加可靠、高效和可扩展。然而,是谷歌的一个团队根据公司的实践写了一本关于 SRE 的书。

除了将软件工程和运营角色结合起来之外,最大的变化是视角的转变。从出现问题时的被动灭火转变为主动强化基础设施是一件大事。它需要预先更加集中注意力,但最终可以通过防止潜在的失败来节省 SRE 员工的时间和公司的资金。

正是这种观点转变导致了混沌工程的创建,作为 SRE 和 DevOps 从业者所接受的一种实践。任何想要证明实施的缓解方案和预防措施确实有效的人突然手头有工具可以做到这一点。

站点可靠性工程师的报酬是多少?


我们在 SRE 与 DevOps 中更深入地讨论了这个问题——它们能共存还是竞争?简短的回答是,薪水很大程度上取决于地点、工程师经验和公司等因素。

截至 2020 年初,美国各地站点可靠性工程师的年薪范围从低端的约 75,000 美元到某些极端偏远情况下的约 450,000 美元或更多。美国的平均工资约为 236,000 美元。在网站可靠性工程师的薪水和库存中赚多少钱中了解更多信息。

成为站点可靠性工程师需要哪些技能?


我们在 SRE 的角色和责任中更深入地讨论了这个问题。

一流的站点可靠性工程师候选人将有一个自然的优先级排序过程。也就是说,他们能够筛选信息并辨别什么是重要的,什么不是。他们还将具有出色的人际沟通技巧。

他们还将拥有一套技能,包括一定程度的熟悉:

  • Git 和 GitHub 和/或 GitLab 等主机
  • Vim(因为这个编辑器在你可能遇到的几乎任何服务器上都可以广泛使用)
  • Linux 基础知识,如包管理、用户帐户管理以及目录和文件权限
  • 基本的服务器软件管理,例如 Apache httpd 或 Nginx
  • SSH
  • Shell 脚本,例如使用 Bash
  • 使用 Python 和 Go 甚至 Rust 等语言进行编程
  • 自动化
  • 联网
  • 监控、日志记录和可观察性
  • 测试,包括编写单元测试和用于 CI 的测试的能力
  • 数据库,包括 MySQL 和 Postgres 等关系数据库,以及至少熟悉 Cassandra、MongoDB 和 Neo4j 等较新的 NoSQL/NewSQL 选项

那些刚进入 SRE 初级职位的人预计不会一开始就了解所有这些,但预计会了解在他们被雇用的系统上成功运行以保持和高效运行所需的内容。有关更多信息,请参阅我们的示例 SRE 职位描述和面试问题文章。

SRE 使用什么工具?


站点可靠性工程有时会很混乱。它一直在变化。在这种环境中管理工作需要计划。跨团队标准化工具集始终是一个好主意。

  • 首先,SRE 必须能够跟踪工作和进度才能取得成功。为此,SRE 组织使用的首批工具之一是一个很好的问题跟踪器,如 JIRA 或 Pivotal Tracker。

SRE 将许多工具与他们管理的软件一起编写。将该代码放在像 Git 这样的存储库中是至关重要的。让每个人都使用相同的 IDE、库和构建过程(例如 Jenkins 或 Spinnaker 等 CI/CD 工具)可以使协作更加高效和顺畅。

  • 将 SRE 团队拥有的服务部署到更广泛的云应用程序架构中的过程很重要。许多团队为此使用 Docker 或 Kubernetes 等容器。

团队通常会自动化他们所能做的一切,包括配置。 Ansible 和 Terraform 等工具对此很有用。

站点可靠性工程如何适应更广泛的工程组织?


在拥有大型云部署的年轻组织中,SRE 角色可能是常态。在仍然拥有企业拥有的数据中心和专门的开发与运营团队的旧组织中,SRE 可能是新的、独特的角色。进化似乎只是反向快速。

在过渡期(在某些情况下可能持续多年),公司可能有一个开发团队仍在使用瀑布方法进行产品开发,并将代码扔给负责使该代码在生产中工作的操作人员。当然,这只是在经过变更审查委员会的多次审查和批准、在测试和阶段环境中的部署等之后。

这些公司可能同时拥有新团队作为试点项目运行,并获得使用敏捷开发方法、DevOps 和/或站点可靠性工程实践以及自动化 CI/CD 管道的许可。这些与更传统的团队并肩作战,有时可能被视为竞争对手。

证明站点可靠性工程的价值的最佳方法是精益求精。学习观点。制定核心价值观。以前所未有的速度推动稳定和需要的功能,并让编写代码的人负责保持其在生产中的良好运行。

团队可能由传统的开发人员/工程师角色、运营专家、监控专家等组成,只有少数团队成员拥有“站点可靠性工程师”的头衔。这并不罕见。在这样的地方,整个团队都拥有代码和运营方面,而 SRE 通常是最了解管理代码的人;构建、部署、配置等。数据库工程师可能仍然是专注于数据可靠性的人,但 SRE 在从她的知识中受益的同时,有助于扩大视野。

归根结底,SRE 是关于协作和合作的,将具有不同技能的人聚集在一起,实现共同目标,让他们有效地分享知识和责任,从而提高系统效率和正常运行时间。

我们如何创建我们的第一个站点可靠性工程团队?


成功的最好方法是首先知道我们正在努力完成什么。我们经常看到项目或范式转变始于太少的计划。当我们学习并需要适应不断变化的环境时,我们希望我们的实施具有灵活性,但我们仍然需要制定计划。

我们首先定义我们的需求。我们希望 SRE 团队做什么?管理?一个好的开始是计划这个新团队将接管一个相对较小的服务或系统。

为什么?因为在这一点上,更广泛的组织正在同时学习文化和流程,并且您希望建立您的第一个团队以取得成功,因为他们有两倍的学习量要做。开始为即将发生的事情准备整个组织。他们需要时间来适应这样一个团队运行的想法。有些人可能会退缩。倾听他们,温柔地教导和引导,但不要走神。

接下来,考虑一下该团队成功所需的工具。不要急于购买它们,因为您可能会聘请一组经验丰富的工程师,他们知道更好的方法和更好的工具,但至少对典型成本进行研究,以便您可以设定初步的预算预期。

这个团队将包括多少人?您是否需要 24/7/365,或者这是一个可以根据需要与一两个随叫随到的人一起工作标准时间的团队?我们建议您的第一个团队使用后者,学习如何在低风险的事情上实施 SRE,然后向上移动。

定义你想在这个 SRE 团队中培养的文化。把它写下来,这样你就可以在接下来创建的工作列表中描述它。

要继续您的员工人数计划,请为您希望为该团队雇用的每个理想候选人编写职位描述。请记住,并非每个人都来自相同的背景,这就是您想要的——多视角!明确团队成员的责任和期望。

决定团队成员是否都将被称为“站点可靠性工程师”,还是将 SRE 与传统角色和头衔混合使用?请记住,单个团队成员可能有专长,但他们都应该为整个团队的所有需求和角色做出贡献,因此您需要灵活的人,他们在分享自己的专业知识时乐于一起学习。

现在,设置第一年的工资预算、团队预算和工具预算。估计比你认为你需要的要高。

我们建议雇佣一批经验丰富的 SRE,他们首先热爱自己的工作。预计最初的 3-4 名领导者将通过了解当今存在的情况、其运作方式以及思考他们想要如何接管来开始工作。考虑内部和外部招聘的混合,以帮助使这一过程在制度上顺利进行,同时也提供一些新的见解和观点。

这些第一批员工需要一点时间来了解彼此的个性、优势和才能,以及他们在整个团队中看到的任何差距。当他们告诉你他们作为一个团队需要什么才能取得成功时,请相信他们的直觉。询问他们接下来要雇用谁,并将他们包括在团队成长过程中。

让他们将运行的系统的经验和学到的知识指导事情从这里开始。

我们如何衡量 SRE 团队的成功?


这里有一些想法。如果我们从编制停机时间和导致问题的故障列表开始,即使没有停机时间,并了解这对公司来说有多么昂贵,那么我们可以将其作为衡量基准。

如果我们实施良好的 SRE 实践并为我们的工程师提供我们团队成功所需的工具和人数,您应该会看到停机时间等事件的数量和严重程度的减少,同时看到更快的响应时间和更小的客户和业务影响。

站点可靠性工程的大部分内容是衡量正确的事情并使用该数据来确定未来的工作优先级。当我们得到错误的初始测量和指标时,我们一注意到就会改变。最好转向新的工具、不同的指标和不断发展的政策,而不是仅仅因为我们有一个想要衡量的现有基线而坚持我们现有的东西。

我们知道我们的正常运行时间何时提高。我们知道我们的网站何时或多或少地响应。我们知道内部和外部客户何时对提供给他们的服务感到满意。衡量你认为最重要的东西,并专注于改进它。当您对该指标的成功感到满意时,请关注另一个指标。主要是选择一些东西来改进和改进它。集中改进,即使是小的改进,加起来。

站点可靠性工程不仅仅是加速灾难恢复。它是关于防止停机,提高系统对压力源的响应能力,并使我们的系统尽可能高效和可靠。

本文:https://jiagoushi.pro/what-site-reliability-engineering

SEO Title
What is Site Reliability Engineering?

IT监控

Chinese, Simplified
SEO Title
IT monitor

【可观察性】什么是可观察性? 不仅仅是日志、指标和跟踪

Chinese, Simplified

随着动态系统架构的复杂性和规模的增加,IT 团队面临着越来越大的压力来跟踪和响应其多云环境中的条件和问题。因此,IT 运营、DevOps 和 SRE 团队都在寻找对这些日益多样化和复杂的计算环境的更高可观察性。

但什么是可观察性?为什么它很重要,它实际上可以帮助组织实现什么?

什么是可观察性?


在 IT 和云计算中,可观察性是根据系统生成的数据(例如日志、指标和跟踪)来衡量系统当前状态的能力。

可观察性依赖于源自多云计算环境中端点和服务的仪器的遥测。在这些现代环境中,每个硬件、软件和云基础架构组件以及每个容器、开源工具和微服务都会生成每个活动的记录。可观察性的目标是了解所有这些环境和技术之间正在发生的事情,这样您就可以检测和解决问题,以保持您的系统高效和可靠,让您的客户满意。

组织通常使用包括开源仪器工具(如 OpenTelemetry)在内的仪器方法组合来实现可观察性。

许多组织还采用可观察性解决方案来帮助他们检测和分析事件对其运营、软件开发生命周期、应用程序安全和最终用户体验的重要性。

近年来,可观察性变得越来越重要,因为云原生环境变得更加复杂,并且故障或异常的潜在根本原因变得更加难以查明。随着团队开始收集和使用可观察性数据,他们也意识到它对业务的好处,而不仅仅是 IT。

由于云服务依赖于独特的分布式和动态架构,因此可观察性有时也可能指企业用来解释云性能数据的特定软件工具和实践。尽管有些人可能将可观察性视为复杂应用程序性能监控 (APM) 的流行词,但在比较可观察性和监控时需要牢记一些关键区别。

监控和可观察性有什么区别?


可观察性真的是用另一个名字来监控吗?简而言之,没有。虽然可观察性和监控是相关的——并且可以相互补充——但它们实际上是不同的概念。

在监控场景中,您通常会预先配置仪表板,这些仪表板旨在提醒您稍后会看到的性能问题。但是,这些仪表板依赖于一个关键假设,即您能够在问题发生之前预测您会遇到哪些类型的问题

云原生环境不适合这种类型的监控,因为它们是动态且复杂的,这意味着您无法提前知道可能会出现什么样的问题。

在可观察性场景中,环境已被充分检测以提供完整的可观察性数据,您可以灵活地探索正在发生的事情并快速找出您可能无法预料的问题的根本原因。

要了解分析师的观点,您可以听听 451 Research 的 Nancy Gohring 如何定义可观察性:

为什么可观察性很重要?


在企业环境中,可观察性有助于跨职能团队理解和回答有关高度分布式系统中正在发生的事情的具体问题。可观察性使您能够了解什么是缓慢或损坏的,以及需要做什么来提高性能。有了可观察性解决方案,团队可以收到有关问题的警报,并在问题影响用户之前主动解决这些问题。

由于现代云环境是动态的,并且在规模和复杂性方面不断变化,因此大多数问题既不为人知,也不被监控。可观察性解决了“未知未知数”这一常见问题,使您能够在新类型问题出现时持续自动地理解它们。

可观察性也是用于 IT 运营 (AIOps) 的人工智能的一项关键能力。随着越来越多的组织采用云原生架构,他们也在寻找实施 AIOps 的方法,利用 AI 作为在整个 DevSecOps 生命周期中自动化更多流程的一种方式。通过将 AI 应用于一切——从收集遥测数据到分析整个技术堆栈中发生的事情——您的组织可以获得对自动化应用程序监控、测试、持续交付、应用程序安全和事件响应至关重要的可靠答案。

可观察性的价值并不仅限于 IT 用例。一旦您开始收集和分析可观察性数据,您就有了一个了解数字服务对业务影响的宝贵窗口。这种可见性使您能够优化转换、验证软件版本是否满足业务目标、衡量您的用户体验 SLO 的结果,并根据最重要的事项确定业务决策的优先级。

当可观察性解决方案还使用综合和真实用户监控分析用户体验数据时,您可以在用户发现问题之前发现问题,并根据真实、即时的反馈设计更好的用户体验。

可观察性的好处


可观察性为 IT 团队、组织和最终用户等提供了强大的优势。以下是可观察性促进的一些用例:

  • 应用程序性能监控:完整的端到端可观察性使组织能够更快地查明应用程序性能问题的根源,包括云原生和微服务环境引起的问题。高级可观察性解决方案还可用于自动化更多流程,提高 Ops 和 Apps 团队的效率和创新。
  • DevSecOps 和 SRE:可观察性不仅是实施高级工具的结果,而且是应用程序及其支持基础设施的基本属性。创建软件的架构师和开发人员必须将其设计为可观察的。然后,DevSecOps 和 SRE 团队可以在软件交付生命周期中利用和解释可观察的数据,以构建更好、更安全、更有弹性的应用程序。
  • 基础设施、云和 Kubernetes 监控:基础设施和运营 (I&O) 团队可以利用可观察性解决方案提供的增强环境来提高应用程序的正常运行时间和性能,减少查明和解决问题所需的时间,检测云延迟问题并优化云资源利用率,并改善对其 Kubernetes 环境和现代云架构的管理。
  • 最终用户体验:良好的用户体验可以提升公司的声誉并增加收入,在竞争中提供令人羡慕的优势。通过在最终用户注意到之前发现并解决问题并在甚至提出要求之前进行改进,组织可以提高客户满意度和保留率。还可以通过实时回放来优化用户体验,获得与最终用户完全一样的体验的窗口,这样每个人都可以很快就改进的地方达成一致。
  • 业务分析:组织可以将业务上下文与全栈应用程序分析和性能相结合,以了解实时业务影响、改进转换优化、确保软件版本满足预期的业务目标,并确认组织遵守内部和外部 SLA。
  • DevSecOps 团队可以利用可观察性来更深入地了解他们开发的应用程序,并自动化测试和 CI/CD 流程,以便他们可以更快地发布质量更好的代码。这意味着组织在作战室和相互指责上浪费的时间更少。从生产力的角度来看,这不仅有好处,而且还能加强对有效协作至关重要的积极工作关系。

这些组织改进为进一步创新和数字化转型打开了大门。而且,更重要的是,最终用户最终会以高质量用户体验的形式受益。

如何使系统可观察?


如果你读过可观察性,你可能知道收集日志、指标和分布式跟踪的测量是取得成功的三个关键支柱。但是,仅从后端应用程序观察原始遥测数据并不能提供系统行为的全貌。

忽视前端视角可能会歪曲甚至歪曲您的应用程序和基础架构在现实世界中为真实用户执行的全貌。扩展三支柱方法,IT 团队必须使用用户体验数据来增加遥测收集,以消除盲点:

  • 日志:这些是在特定时间发生的离散事件的结构化或非结构化文本记录。
  • 指标:这些值表示为计数或度量,通常在一段时间内计算或汇总。指标可以来自多种来源,包括基础设施、主机、服务、云平台和外部来源。
  • 分布式跟踪:这会显示事务或请求在流经应用程序时的活动,并显示服务如何连接,包括代码级详细信息。
  • 用户体验:这扩展了传统的可观察性遥测,通过在应用程序上添加特定数字体验的由外而内的用户视角,即使在预生产环境中也是如此。

为什么可观察性的三大支柱还不够


显然,数据收集仅仅是开始。仅仅访问正确的日志、指标和跟踪并不足以获得对环境的真正可观察性。一旦你能够使用遥测数据来实现改善最终用户体验和业务成果的最终目标,你才能真正说你已经实现了可观察性的目的。

组织可以使用其他可观察性功能来观察其环境。 OpenTelemetry 等开源解决方案为在云环境中收集遥测数据提供了事实上的标准。这些开源解决方案增强了云原生应用程序的可观察性,并使开发人员和运营团队更容易在多个环境中实现对应用程序健康状况的一致理解。

组织还可以使用真实用户监控来实时了解用户体验,跟踪单个请求的路径,并深入了解它在此过程中与每项服务的每次交互。这种体验可以通过综合监控甚至实际会话的记录来观察。这些功能通过从用户角度添加 API、第三方服务、浏览器中发生的错误、用户人口统计和应用程序性能的数据来扩展遥测。这使 IT、DevSecOps 和 SRE 团队不仅能够查看请求的完整端到端旅程,还能够实时了解系统运行状况。从那里,他们可以在影响应用程序性能之前主动排除运行状况恶化的区域。他们还可以更轻松地从故障中恢复,并更深入地了解用户体验。

尽管 IT 组织拥有最好的意图和策略,但他们经常高估已经负担过重的团队不断观察、理解和处理海量数据和洞察力的能力。尽管存在与可观察性相关的许多复杂挑战,但克服这些挑战的组织会发现值得一试。

可观察性的挑战是什么?


可观察性一直是一个挑战,但云计算的复杂性和快速的变化使其成为组织需要解决的紧迫问题。云环境会生成大量遥测数据,尤其是在涉及微服务和容器化应用程序时。他们还创建了比团队过去必须解释的更多种类的遥测数据。最后,所有这些数据到达的速度使得跟上信息流变得更加困难,更不用说及时准确地解释它以解决性能问题了。

组织还经常遇到以下可观察性挑战:

  • 数据孤岛:多个代理、不同的数据源和孤立的监控工具使得很难理解应用程序、多个云和数字渠道(如 Web、移动和物联网)之间的相互依赖关系。
  • 数量、速度、多样性和复杂性:几乎不可能从不断变化的现代云环境(例如 AWS、Azure 和 Google 云平台 (GCP))中每个组件收集的大量原始数据中获得答案。对于 Kubernetes 和可以在几秒钟内启动和关闭的容器也是如此。
  • 手动检测和配置:当 IT 资源被迫为每种新类型的组件或代理手动检测和更改代码时,他们大部分时间都在尝试设置可观察性,而不是根据可观察性数据的见解进行创新。
  • 缺乏预生产:即使在预生产中进行负载测试,开发人员仍然无法观察或了解真实用户在将代码投入生产之前将如何影响应用程序和基础设施。
  • 浪费时间进行故障排除:应用程序、运营、基础设施、开发和数字体验团队参与故障排除并尝试找出问题的根本原因,浪费宝贵的时间猜测并尝试理解遥测并提出答案。
  • 然后,存在多个工具和供应商的问题。虽然单个工具可以让组织对其应用程序架构的一个特定区域具有可观察性,但该工具可能无法提供对可能影响应用程序性能的所有应用程序和系统的完全可观察性。

此外,并非所有类型的遥测数据对于确定问题的根本原因或了解其对用户体验的影响都同样有用。因此,团队仍然需要在多个解决方案中挖掘答案并煞费苦心地解释遥测数据的耗时任务,而此时他们可以应用他们的专业知识来立即解决问题。但是,通过单一的事实来源,团队可以更快地获得答案并解决问题。

单一事实来源的重要性


组织需要单一的事实来源才能在其应用程序基础架构中获得完整的可观察性,并准确查明性能问题的根本原因。当组织拥有可以控制云复杂性、捕获所有相关数据并使用 AI 进行分析的单一平台时,团队可以立即确定任何问题的根本原因,无论是应用程序本身还是支持架构。

单一的事实来源使团队能够:

  • 将 TB 的遥测数据转化为真正的答案,而不是要求 IT 团队使用来自不同来源的数据片段拼凑对发生的事情的理解
  • 获得对他们可能无法看到的基础设施领域的关键上下文洞察。
  • 协同工作并进一步加快故障排除过程,使组织能够比使用传统监控工具更快地采取行动,这要归功于增强的可见性。

使 IT 团队的可观察性具有可操作性和可扩展性


可观察性必须以允许资源受限的团队对实时收集的大量遥测数据采取行动的方式实现,以防止影响业务的问题进一步传播甚至首先发生。这里有一些方法可以使可观察性具有可操作性和可扩展性。

  • 了解上下文和拓扑:这涉及以一种方式进行检测,以了解高度动态、多云环境中可能存在数十亿个互连组件的每个相互依赖关系之间的关系。丰富的上下文元数据支持实时拓扑图,提供对整个堆栈垂直和服务、进程和主机之间的因果依赖关系的理解。
  • 实施持续自动化:持续自动发现、检测和基线化每个系统组件,将 IT 工作从手动配置工作转移到增值创新项目,这些项目可以优先考虑对重要事物的理解。可观察性变得“永远在线”和可扩展,因此受限团队可以事半功倍。
  • 建立真正的 AIOps:详尽的 AI 驱动的故障树分析与代码级可见性相结合,解锁了自动查明异常根本原因的能力,而无需依赖耗时的人工试错、猜测或关联。此外,基于因果关系的人工智能可以自动检测任何不寻常的变化点,以发现未被理解或监控的“未知未知数”。这些可操作的洞察力推动了 DevOps 和 SRE 团队所需的更快、更准确的响应。
  • 培育一个开放的生态系统:这将可观察性扩展到包括外部数据源,例如 OpenTelemetry,这是一个由 Dynatrace、Google 和 Microsoft 等供应商领导的开源项目。 OpenTelemetry 为提供拓扑映射、自动发现和检测以及大规模可观察性所需的可操作答案的平台扩展了遥测收集和摄取。

人工智能驱动的基于解决方案的方法通过解决与云复杂性相关的挑战,使可观察性真正可行。可观测性解决方案可以更轻松地解释以越来越快的速度从多个来源产生的大量遥测数据。借助单一事实来源,团队可以在问题导致应用程序性能下降之前快速准确地查明问题的根本原因,或者在已经发生故障的情况下加快恢复时间。

高级可观察性还通过跨无服务器平台、Kubernetes 环境、微服务和开源解决方案的端到端分布式跟踪来提高应用程序的可用性。通过了解请求从开始到结束的整个过程,团队可以主动识别应用程序性能问题并获得对最终用户体验的重要洞察。这样,即使组织扩展其应用程序基础架构以支持未来的增长,IT 团队也可以迅速对关注的问题采取行动。

为一切带来可观察性


您不能浪费数月或数年时间尝试构建自己的工具或测试多个供应商,这些供应商只能让您解决可观察性难题的一部分。相反,您需要一个解决方案来帮助您的所有系统和应用程序可观察,为您提供可操作的答案,并尽快提供技术和业务价值。

Dynatrace 的高级可观察性在单个平台中提供所有这些功能,使您的组织能够驾驭现代云复杂性并更快地进行转型。

原文:https://www.dynatrace.com/news/blog/what-is-observability-2/

本文:https://jiagoushi.pro/node/1928

SEO Title
What is observability? Not just logs, metrics and traces

【监控】使用开源Grafana和InfluxDB可视化时间序列数据

Chinese, Simplified

NGINX最近委托约1825名NGINX用户进行的一项调查显示,约68%的受访者组织正在使用或调查微服务,66%的受访者组织正在使用或调查容器。当您谈论一个样本池的“三分之二”时,您正在处理一个相当大的区块。

不管怎样,你要问其他的NX用户在做什么。

正如本出版物的读者所知,采用这些技术是有代价的。DevOps团队通常会比以前有更多的活动部件需要监控。更重要的是,他们正在监控更多短暂的组件,这可能会促使他们使用几种不同的监控解决方案。

InfluxData的InfluxDB和Grafana这两个流行的开源项目的合作可以帮助他们监视和控制云基础设施、应用程序和数据库实例以及容器,从而为DevOps提供一个统一的视图或单一的窗口。

InfluxData提供了一个时间序列数据平台,用于收集和存储用于监控的度量和事件。它包括一个流引擎和100多个收集器代理,用于从多个源收集度量并将其存储在时间序列数据库中。该数据库针对高写负载和大数据集存储进行了优化。它通过下采样、自动过期和删除不需要的数据来节省空间。它还带有一个优雅的UI,支持警报阈值,可以触发流行的工具,如HipChat、OpsGenie、Alerta、Sensu、PagerDuty和Slack。

Grafana是一个供应商中立、开源的时间序列分析平台,拥有超过100000个活动安装。DevOps团队求助于Grafana实验室,帮助他们将不同的数据源整合在一起。它与扩展数据的无缝集成使其成为可视化收集的度量的理想工具。

如何设置Grafana和XDB

您可以从这里下载XDB和相关工具,也可以从这里下载Grafana。

对于扩展数据,您需要一个代理来收集和存储度量。我们推荐我们自己的Telegraf,它有100多个插件,尽管您可以使用传统的收集代理,如StatsD。

XDB和Grafana进程可能共享同一服务器或同一实例。但是,如果您希望安装大量XDB、拥有大量Grafana用户,或者如果您的组织具有特别严格的安全态势或部署配置文件,那么单独的服务器也是完全可以接受的。XDB的API通常默认为端口8086,Grafana的默认为端口3000。Grafana将查询XDB API,以便为仪表板收集数据。

在这两个应用程序中,InfluxDB将是内存和CPU密集度更高的应用程序,因为Grafana的许多工作都发生在一个非常轻量级的基于浏览器的应用程序中。

InfluxDB和 Grafana安装配置

在一起设置InfluxDB和Grafana的默认配置时,可以启用查询日志,该日志将记录执行或发送到InfluxDB API时的所有查询。这样的日志对于调试Grafana问题可能很有用。使用配置的coordinator部分设置最大并发查询数。这可能有助于改善多个Grafana用户同时通过查询访问XDB的问题。您还可以设置查询超时,并记录查询运行缓慢时的时间。

“最大选择点”、“最大选择系列”和“最大选择存储桶”设置限制可以返回的结果数。这可以帮助阻止一个特别扩展的查询减慢或关闭XDB服务器。

Grafana的配置文件包括一些有用的设置,如http端口和路由器日志记录,加快了浏览器的加载时间。

Grafana的安全设置

每个Grafana实例都有一个默认的管理员用户和密码,您需要对其进行更改。默认情况下,Grafana的注册过程允许非管理员用户创建组织。因此,我们建议将“启用匿名访问”选项设置为“false”

如果您打算调试Grafana,那么您肯定会提高日志级别进行调试。Grafana将公布有关自身的指标。Telegraf有一个内置的普罗米修斯输入,所以你可以把它指向Grafana。这样,您可以收集内部指标,将它们放入XDB,然后在Grafana中绘制它们的图形。

如果您正在使用InfluxCloud,并且需要配置对Grafana上不同组和用户的访问权限,请查看以下简短的网络研讨会:“InfluxCloud与多租户Grafana”同样,要使用Grafana UI设置图形并利用InfluxDB查询生成器,请参阅“如何将Grafana与InfluxDB一起使用”

构建仪表板并设置图表

Grafana的仪表盘与上面的仪表盘一样,是一组行和面板,一旦选择XDB作为其数据源,就可以编辑这些行和面板。可以轻松更改图形显示为直线、条形或点的方式。在这些图中,您可以使用任何喜欢的聚合器,选择多个字段,或者使用移动平均等转换。

每个Grafana图实际上都是对InfluxDB的查询。如果您有一个包含30个图形的仪表板,那么您将向InfluxDB发送30个查询,以及需要由InfluxDB整理结果,然后通过Grafana发送回的30个查询。考虑过多的图表是否对你有用。

尽管Grafana对一个图表上显示的指标数量没有限制,但您仍希望跟踪对您监控性能、提取见解或启用预测最有用的指标。

这两个开源项目应该非常适合您的DevOps监控项目,并且不需要花时间进行设置和定制。

原文:https://thenewstack.io/visualize-time-series-data-open-source-grafana-i…

本文:https://jiagoushi.pro/node/1788

SEO Title
Visualize Time-Series Data with Open Source Grafana and InfluxDB

IT配置管理

Chinese, Simplified

什么是配置管理

配置管理(CM)是一个系统工程过程,用于建立和维护产品性能、功能和物理属性与其整个生命周期内的需求、设计和操作信息的一致性。CM管理过程被军事工程组织广泛用于管理复杂系统(如武器系统、军用车辆和信息系统)整个系统生命周期内的变更。在军队以外,构型管理流程还用于ITIL定义的IT服务管理,以及土木工程和其他工业工程领域的其他领域模型,如道路、桥梁、运河、水坝和建筑物。

介绍

在系统生命周期中应用的CM提供了对其性能、功能和物理属性的可见性和控制。CM 验证系统是否按预期运行,并被识别和详细记录以支持其预计的生命周期。CM过程有助于有序管理系统信息和系统变更,以达到修改能力等有利目的;提高性能、可靠性或可维护性;延长寿命;降低成本;减少风险和责任;或纠正缺陷。实施CM的相对最低成本在避免成本方面返回了许多倍。缺乏CM或其无效实施可能非常昂贵,有时可能会造成灾难性后果,如设备故障或生命损失。

CM强调零件、子系统和系统之间的功能关系,以有效控制系统变更。它有助于验证是否系统地考虑了提议的变更,以尽量减少不利影响。使用标准化、系统化的方法提出、评估和实施系统变更,以确保一致性,并根据拟定变更对整个系统的预期影响对其进行评估。构型管理验证变更是否按照规定执行,项目和系统的文件是否反映其真实配置。完整的构型管理计划包括存储、跟踪和更新组件、子系统和系统的所有系统信息。

结构化构型管理计划确保项目的文件(如要求、设计、测试和验收文件)准确且与项目的实际物理设计一致。在许多情况下,如果没有CM,文档是存在的,但与项目本身不一致。因此,工程师、承包商和管理层经常被迫在进行变更前编制反映项目实际状态的文件。这种逆向工程过程在人力和其他资源方面是浪费的,可以使用CM最小化或消除。

历史

配置管理起源于20世纪50年代的美国国防部,作为硬件材料项目的技术管理规程,现在几乎在每个行业都是标准做法。20世纪60年代末,国防部制定了一系列军事标准,称为“480系列”(即MIL-STD-480、MIL-STD-481和MIL-STD-483),随后于20世纪70年代发布,构型管理过程成为了自己的技术规程。1991年,“480系列”被合并为一个称为MIL–STD–973的单一标准,然后根据国防部的一个总体目标,即减少军事标准的数量,以支持由标准开发组织(SDO)支持的行业技术标准,由MIL–HDBK–61取代。[7] 这标志着现在已经发展成为最广泛分发和接受的CM标准ANSI-EIA-649-1998的开始。CM学科的概念现在被许多组织和机构广泛采用,包括系统工程(SE)、集成后勤支持(ILS)、能力成熟度模型集成(CMMI)、ISO 9000、Prince2项目管理方法、COBIT、ITIL、产品生命周期管理和应用生命周期管理。许多这些功能和模型已经从传统的整体技术管理方法中重新定义了CM。一些人将CM视为类似于图书馆员的活动,并将变更控制或变更管理作为一个单独或独立的学科。

 

概述


CM 是系统地处理变更的实践,以便系统随着时间的推移保持其完整性。 CM 实施策略、程序、技术和工具,用于管理、评估提议的变更、跟踪变更状态并在系统变更时维护系统和支持文档的清单。 CM 计划和计划为成功开发和支持复杂系统所需的程序、功能、服务、工具、流程和资源的开发和实施提供技术和管理指导。在系统开发期间,CM 允许项目管理人员在整个生命周期中通过验收、操作和维护跟踪需求。由于需求和设计中不可避免地会发生更改,因此必须对其进行批准和记录,以创建系统状态的准确记录。理想情况下,CM 过程应用于整个系统生命周期。大多数专业人士与资产管理(AM,另见 ISO/IEC 19770)混淆或混淆,资产管理在其中盘点手头资产。 CM 和 AM 之间的主要区别在于,前者不管理财务会计方面,而是管理系统支持的服务,或者换句话说,后者 (AM) 试图从 IT 资产中实现价值。

硬件和软件配置项目的 CM 过程包括五个不同的学科,如 MIL-HDBK-61A[12] 和 ANSI/EIA-649 中所建立。这些纪律[由谁?] 执行,作为建立基线和执行标准变更管理过程的政策和程序。 IEEE 12207 流程 IEEE 12207.2 也有这些活动并添加了“发布管理和交付”。这五个学科是:

  • CM 计划和管理:指导 CM 计划的正式文件和计划,包括以下项目:
    • 人员
    • 职责和资源
    • 培训要求
    • 行政会议指南,包括程序和工具的定义
    • 基线流程
    • 配置控制和配置状态计费
    • 命名约定
    • 审计和审查
    • 分包商/供应商 CM 要求
  • 配置标识 (CI):包括设置和维护基线,这些基线定义了系统或子系统架构、组件以及任何时间点的任何开发。它是对系统任何部分的更改进行识别、记录并随后通过设计、开发、测试和最终交付进行跟踪的基础。 CI 在系统及其配置项 (CI) 的整个生命周期(开发、生产、部署和运营支持)中逐步建立和维护系统的配置状态核算 (CSA) 的当前确定性基础,直至处置。
  • 配置控制:包括对所有变更请求和变更建议的评估,以及它们随后的批准或不批准。它涵盖了控制对系统设计、硬件、固件、软件和文档进行修改的过程。
  • 配置状态核算:包括记录和报告配置项描述(例如,硬件、软件、固件等)以及设计和生产期间所有偏离基线的过程。如果出现疑似问题,可以快速确定基线配置的验证和批准的修改。
  • 配置验证和审计:对硬件和软件的独立审查,目的是评估是否符合既定的性能要求、商业和适当的军事标准,以及功能、分配和产品基线。配置审核验证系统和子系统配置文档是否符合功能和物理性能特征,然后再纳入架构基线。

软件


主条目:软件配置管理
软件配置管理 (SCM) 过程被从业者视为处理软件项目变更的最佳解决方案。它在各个时间点标识软件的功能和物理属性,并对标识的属性的更改进行系统控制,以在整个软件开发生命周期中保持软件的完整性和可追溯性。

SCM 过程进一步定义了跟踪更改的需求,以及验证最终交付的软件是否具有应该包含在发布中的所有计划增强功能的能力。它确定了必须为每个软件项目定义的四个过程,以确保实现一个健全的 SCM 过程。他们是:

  • 配置标识
  • 配置控制
  • 配置状态记账
  • 配置审计

这些术语和定义因标准而异,但本质上是相同的。

  • 配置识别是识别定义配置项每个方面的属性的过程。配置项是具有最终用户用途的产品(硬件和/或软件)。这些属性记录在配置文档中并建立基线。在这些属性发生更改的情况下,对属性进行基线化会强制实施正式的配置更改控制过程。
  • 配置更改控制是更改配置项的属性和重新设置它们的基线所需的一组流程和批准阶段。
  • 配置状态核算是在任何时间记录和报告与每个配置项关联的配置基线的能力。
  • 配置审计分为功能和物理配置审计。它们要么发生在交付时,要么发生在改变生效的那一刻。功能配置审计确保实现配置项的功能和性能属性,而物理配置审计确保配置项按照其详细设计文档的要求进行安装。

配置管理数据库(CMDB)


ITIL 指定使用配置管理系统 (CMS) 或配置管理数据库 (CMDB) 作为实现配置管理行业最佳实践的手段。 CMDB 用于跟踪配置项 (CI) 及其之间的依赖关系,其中 CI 代表企业中值得跟踪和管理的事物,例如但不限于计算机、软件、软件许可证、机架、网络设备、存储,甚至此类项目中的组件。

CMS/CMDB 的好处包括能够执行诸如根本原因分析、影响分析、变更管理和当前状态评估等功能,以用于未来状态战略的制定。示例系统通常将自己标识为 IT 服务管理 (ITSM) 系统,包括 FreshService、ServiceNow 和 Samanage。

信息保障


对于信息保障,CM 可以定义为通过控制在信息系统的整个生命周期中对硬件、软件、固件、文档、测试、测试装置和测试文档所做的更改来管理安全特性和保证。 [13] [需要更好的来源] 用于信息保证的 CM,有时也称为安全配置管理,它依赖于 IT 平台和产品及其环境的性能、功能和物理属性来确定用于衡量系统的适当安全特性和保证配置状态。例如,作为组织 Internet 边界一部分的网络防火墙与作为内部本地网络防火墙的网络防火墙的配置要求可能不同。

维护系统


配置管理用于保持对复杂资产状态的理解,以期以最低成本保持最高水平的可服务性。具体而言,它旨在确保运营不会因资产(或资产的一部分)超出计划寿命限制或低于质量水平而中断。

在军队中,这种类型的活动通常被归类为“任务准备”,旨在确定哪些资产可用以及用于哪种类型的任务;一个典型的例子是航空母舰上的飞机是否配备了用于地面支持的炸弹或用于防御的导弹

操作系统配置管理


配置管理可用于维护操作系统配置文件。 [14]示例系统包括 Ansible、Bcfg2、CFEngine、Chef、Nix、Otter、Puppet、Quattor、SaltStack、Terraform、Pulumi 和 Vagrant。其中许多系统利用基础设施即代码来定义和维护配置。

配置维护的 Promise 理论是由 Mark Burgess 开发的,在当今的计算机系统中,CFEngine 软件能够执行实时修复和预防性维护,并在计算机系统上进行了实际实施。

预防性的维护


主条目:预防性维护
了解资产及其主要组件的“原样”状态是维护、修理和检修以及企业资产管理系统中使用的预防性维护的基本要素。

复杂的资产,如飞机、船舶、工业机械等,取决于许多不同的部件是否可用。这种适用性通常根据组件自新、自安装、自维修以来的使用量、它在其整个生命周期中的使用量以及其他几个限制因素来定义。了解这些组件中的每一个如何接近使用寿命一直是一项涉及劳动密集型记录保存的重大任务,直到软件的最新发展为止。

预测性维护


主条目:预测性维护
许多类型的组件使用电子传感器来捕获提供实时状态监控的数据。计算机在船上或远程位置对这些数据进行分析,以评估其当前的适用性,并越来越多地使用算法来评估其可能的未来状态,这些算法基于先前的故障示例通过现场经验和建模来预测潜在的未来故障。这是“预测性维护”的基础。

准确及时的数据可用性对于 CM 提供运营价值至关重要,而缺乏这一点通常会成为一个限制因素。捕获运营数据并将其传播给各种支持组织本身正在成为一个行业。

随着原始设备制造商 (OEM) 提供的程序的增长,这些数据的消费者变得越来越多、越来越复杂。这些旨在为运营商提供有保障的可用性,并使运营商管理资产的情况变得更加复杂,但 OEM 承担确保其可服务性的责任。

标准


许多标准支持或包括配置管理,[19] 包括:

  • ANSI/EIA-649-1998 国家配置管理共识标准
  • EIA-649-A 2004 国家配置管理共识标准
  • ANSI EIA-649-C 2019 配置管理标准
  • ISO 10007 质量管理体系 – 配置管理指南
  • 联邦标准 1037C
  • GEIA 标准 836–2002 配置管理数据交换和互操作性
  • IEEE 829 软件测试文档标准
  • 828-2012 IEEE 系统和软件工程配置管理标准。 2012. doi:10.1109/IEEESTD.2012.6170935。 ISBN 978-0-7381-7232-3。
  • MIL-STD-973 配置管理(2000 年 9 月 20 日取消)[20]
  • NATO STANAG 4427 系统生命周期管理中的配置管理,包括
  • NATO ACMP 2000 配置管理政策
  • NATO ACMP 2009 配置管理指南[21]
  • NATO ACMP 2100 配置管理合同要求
  • CMMI 用于开发的 CMMI,版本 1.2 配置管理
  • CMII-100E CMII 企业配置管理标准[22]
  • 配置管理及相关标准的扩展列表[23]
  • ITIL 服务资产和配置管理
  • ISO 20000:1 2011 & 2018 服务管理体系。
  • ECSS-M-ST-40C Rev.1 配置和信息管理[24]


指南

 

  • IEEE 828-2012 系统和软件工程配置管理标准,[25] 发布日期:2012-03-16
  • ISO 10007:2017 质量管理——配置管理指南[26]
  • NATO ACMP-2009 – 配置管理指南[21]
  • ANSI/EIA-632-1998 系统工程流程
  • ANSI/EIA-649-1998 国家配置管理共识标准
  • GEIA-HB-649 – 配置管理实施指南
  • EIA-836 配置管理数据交换和互操作性共识标准
  • MIL-HDBK-61B 配置管理指南,[27] 2020 年 4 月 7 日
  • MIL-STD-3046 配置管理,[28] 2013 年 3 月 6 日,2015 年 6 月 1 日取消
  • 国防采办指南,[29] 4.3.7 SE 流程中的 CM 元素,5.1.7 生命周期支持中的 CM 属性
  • 系统工程基础,第 10 章配置管理[30]
  • 配置管理计划美国国防部采购文件[31]

建造


最近[何时?] 配置管理已应用于大型建设项目,这些项目通常非常复杂,并且需要记录大量细节和更改。联邦公路管理局等建筑机构已将配置管理用于其基础设施项目。 [32]有一些基于施工的配置管理工具,旨在记录变更单和 RFI,以确保项目按计划和预算进行。这些程序还可以存储信息,以在基础设施完成时帮助维护和修改基础设施。一个这样的应用程序 ccsNet 在由联邦运输管理局 (FTA) 资助的案例研究中进行了测试,其中首先通过比较洛杉矶县大都会交通局 (LACMTA) 大约 80% 的完整建设来衡量配置管理的有效性红线的第二段,一个耗资 53 亿美元的铁路建设项目。这项研究的结果表明在这种性质的项目上使用配置管理是有益的。 

CM

原文:https://en.wikipedia.org/wiki/Configuration_Management_(ITSM)

 

配置管理(ITSM)

什么是配置管理(ITSM)?

配置管理 (CM) 是 ITIL 版本 2 和 IT 服务管理 (ITSM) 流程,用于跟踪 IT 系统中的所有单个配置项 (CI),该系统可能像单个服务器一样简单,也可能像整个系统一样复杂 IT部门。 在大型组织中,可能会任命一名配置经理来监督和管理 CM 过程。 在 ITIL 版本 3 中,此流程已重命名为服务资产和配置管理。

配置项

 

配置项(CI)是可能依赖于其他IT流程和/或与其他IT流程有关系的IT资产或IT资产的组合。CI将具有可能是分层的属性和将由配置管理器在CM数据库中分配的关系。

属性

  • 技术–描述CI功能的数据,包括软件版本和型号、硬件和制造商规格以及其他技术细节,如网络速度和数据存储大小。键盘、鼠标和电缆被视为耗材。
  • 所有权–金融资产管理的一部分,所有权属性记录CI的购买日期、保修、地点和负责人。条形码和类型等标识号,如软件、硬件和文档也是所有权属性。
  • 关系–硬件项目(如打印机)、软件(如驱动程序)和用户(如Alice)之间的关系。

配置管理数据库(CMDB)

CM 的基本组件是 CM 数据库 (CMDB),它包含 CI 信息,用于了解 CI 关系并跟踪其配置等.

活动


CMDB 中的信息用于五项基本活动:

  • 计划:CM 计划详细涵盖了接下来的三到六个月,以及接下来的十二个月的大纲。每年至少审查两次,将包括战略、政策、范围、目标、角色和职责、CM 流程、活动和程序、CMDB、与其他流程和第三方的关系,以及工具和数量要在 CMDB 中跟踪的 CI 类别决定了范围。 CI信息的细节是深度。
  • 标识:所有 CI 的选择、标识和标记,它创建系统中每个 CI 的部件列表。这涵盖了有关 CI 信息的记录,包括硬件和软件版本、文档、所有权和其他唯一标识符。 CI 应该按照业务需要的详细程度进行记录,通常达到“独立更改”的级别。这包括定义系统中 CI 的关系。
  • 控制:这可确保从接收到处置只接受和记录经授权和可识别的 CI。它确保在没有适当控制文档的情况下不会添加、修改、替换或删除 CI。已批准的 CI 更改请求、更新的规范。所有 CI 都将受变更管理 (ITSM) 控制。
  • 监控:关注每个 CI 的整个生命周期。它支持更改 CI 并通过各种状态跟踪其记录,例如订购、接收、测试、使用、维修、撤回或处置。
  • 验证:审查和审计验证 CI 的物理存在,并检查它们是否正确记录在 CMDB 和部件列表中。它包括在对实时环境进行更改之前验证发布管理 (ITSM) 和 CM 文档的过程。

原文:https://en.wikipedia.org/wiki/Configuration_Management_(ITSM)

SEO Title
IT configuration management

【DevOps】Ansible v.s. Salt (SaltStack) v.s. StackStorm

Chinese, Simplified

在过去的一个月里,我听取了对所有 3 种产品的开发人员的采访,并听到了“将 [Ansible/Salt/StackStorm] 视为粘合剂”的说法。现在,我是一个 DIY 爱好者,我可以放心地告诉大家,我的车库里没有 1 罐胶水。根据工作、材料和环境,我有 6 种不同的类型。这 3 个产品属于同一个阵营,它们都可以用来取得巨大的成功来实现非常不同的事情,最近一个很大的重叠是它们正在进入网络自动化领域。以下观点仅代表我个人,而不是我的雇主(他们出售了数十亿美元的网络基础设施和部署)。


我使用了所有 3 个产品,对 2 个(Salt 和 StackStorm)做出了重大贡献,并参与了对 Ansible 的贡献。坦率地说,我最不熟悉的产品是 Ansible,但我已经说过并从同事那里收集信息以在适当的时候填补空白。


如果你要跳到最后,看看我宣布哪个获胜者——你会失望的。考虑您的要求并尝试其中一种以上的产品。

一些问题要问自己:

  • 我需要支持哪些环境?我的服务器和网络设备的组合是什么?
  • 谁是我的用户?这是针对核心系统管理员类型、信息安全团队、开发人员的吗?
  • 我愿意做多少定制开发?

代理 v.s.无代理


这真的很重要,所以请注意。在本文中,我将重点关注设备自动化和编排。这些设备可能是路由器、交换机、防火墙、下一代波发射循环器,都没有关系。重要的是他们不会在操作系统中安装代理。 Ansible 拥有使用 SSH 作为传输的传统,因此非常适合 SSH 是最低公分母的端点配置世界SaltStack 是作为高速和安全的 Minion(代理)掌握通信的总线而诞生的,它也具有无代理模式 StackStorm 是最后进入该领域的,并且在设计上远离任何一种选择,它通过面向 Chef、Puppet、Salt 的包支持基于代理的工具,以及它自己的基于 SSH 的远程控制和对调用 Ansible 剧本的本机支持。
 

API


另一个关键区别是 API,

  • Ansible 可用作 CLI,Ansible Tower(企业版)有一个 API,
  • StackStorm 有一个 CLI,但也有免费版本中所有组件和服务的 REST API,
  • Salt 有 CLI 和 REST API(默认情况下未启用),您还可以使用“Enterprise API”作为包含 RBAC 等功能的 Enterprise 产品的一部分。


Ansible


Ansible 是 Michael DeHaan 的创意,开发用于在大型环境中自动化繁琐的服务器管理任务。 Michael 曾在 RedHat 的新兴技术小组工作,在那里他创立了 Cobbler 等其他项目,然后在离开 RedHat 后继续创立 Ansible(尽管 Ansible 现在归 RedHat 所有)。从迈克尔关于 Ansible 基础的博客中,它的目的很明确;
“我们想在 Red Hat 创建另一个非常民主的开源项目,该项目可以拥有广泛的贡献者并解决新问题。我们又想到了busrpc。这个项目存在是因为它填补了 Cobbler 和 Puppet 之间的空白。 Cobbler 可以提供一个系统,而 Puppet 可以放置配置文件,但是因为 Puppet 过于声明性,你不能用它来做诸如重启服务器之类的事情或在两者之间执行所有“临时”任务”
这些临时任务演变成 Ansible 剧本,Ansible 模块生态系统迅速诞生并蓬勃发展。

设计


Ansible 很简单,这是一个主要优势(并且在查看其他 2 个时会变得清晰)。没有守护进程,没有数据库,安装要求非常低。您只需在 Linux 机器上安装 Ansible 即可。在静态文件中定义目标服务器,将其分组为有意义的部分,或者使用动态主机发现模块(如 Amazon EC2 或 OpenStack)根据 API 调用查找 VM。一旦你有了清单,你就可以构建主机或组特定的变量,你的剧本可以利用这些变量。这些再次保存在静态文本文件中。
然后 Ansible 将连接到您选择的主机或组并执行剧本。 playbook 是一系列 Ansible 模块,您希望在使用 YAML 编写的远程主机上执行这些模块。
当它连接到远程主机时,这有点像精心策划的军事演习,上车、干活然后下车。
Ansible 的工作原理是使用 SSH(或 Windows 的 WS-Man/WinRM)连接到服务器,复制 Python 代码,执行它,然后自行删除。


架构


Ansible 的架构很简单,你有在你的机器上运行的应用程序,你有在远程主机上运行的任务,通过 SSH 进行通信并通过 SCP/SFTP 传输文件。 Ansible 没有像其他 2 个产品那样的“服务器-客户端”架构,因此您可以在机器上并行执行任务,但不能跨多个服务器扩展(除非您使用 Tower)。
当 Ansible 管理远程机器时,它不会在这些机器上安装或运行软件,因此在迁移到新版本时如何升级 Ansible 没有真正的问题。


可扩展性


Ansible 模块真的很容易开发,与所有 3 个产品一样,如果您以后决定尝试将您的解决方案合并到产品的开源存储库中,而不是再次重构它,请阅读样式指南。

#!/usr/bin/python

import datetime
import json

date = str(datetime.datetime.now())
print json.dumps({
    "time" : date
})

ansible/hacking/test-module -m ./timetest.py

您应该会看到如下所示的输出:

{"time": "2012-03-14 22:13:48.539183"}

在模块中,您可以定义自己的“收集”阶段代码,以建立有关远程主机的“事实”,供您或其他模块使用。 这可能类似于查看安装的文件或配置以确定服务的设置方式。


企业支持


Ansible Tower 是企业版,它将命令行 Ansible 变成一个服务,具有 Web 界面、调度程序和通知系统。

Task Scheduler

它还具有用于云部署手册的 UI,因此您可以通过 UI 自动部署云基础架构,然后自动将这些 VM 添加到清单中。
值得注意的是,任务调度、云部署和服务器是 Salt 和 StackStorm 免费版本的功能。


网络支持


Ansible 的网络故事是三者中最成熟的,涵盖所有主要网络供应商和平台,借助 Ansible,您可以:

  • 通过使用网络平台特定的模块和脚本,自动配置从系统到核心服务访问的网络堆栈
  • 测试和验证现有网络状态,实施或利用收集过程来确定有关现有配置的事实
  • 持续合规以检查网络配置漂移

Ansible 支持 Arista、Cisco(所有可编程平台)、F5、Juniper 以及其他供应商。 Ansible 的独特之处在于,供应商支持主要由供应商提供和支持,而不是社区。目前,这表明 API 覆盖范围更广、功能更多、平台支持更新(支持更新版本)。


优势

 

  • 非常快速和简单的开始
  • 大量社区示例、文档和模块
  • Ansible Tower 为大型企业部署实施功能
  • 供应商支持的网络模块


弱点

 

  • 如果无人监管,操作员可以将剧本和 SSH 密钥完全保存在他们自己的笔记本电脑上。不完全是 Ansible 的错,但要密切关注这一点,
  • 没有事件驱动的自动化故事,你可以在剧本的持续时间内控制目标主机,就是这样,你不能有长时间运行的任务。

StackStorm


我从 v0.11(早期预测试版)一直使用 StackStorm,一直到最新的 v2.2。这是一个复杂而广泛的平台,就像 Salt 一样,需要一段时间才能向人们描述,并且经常会导致误解。我认为这既是优点也是缺点。这是一个弱点,因为它的复杂性可能会令人反感,并导致人们部署错误的解决方案,而 StackStorm 非常适合(通常人们从头开始编写自己的解决方案)。一旦你了解如何利用它的力量,它就会变得非常灵活。

StackStorm UI

设计


StackStorm 的核心是一个可插入的规则和执行引擎,它被设计为一个高度可配置的 IFTTT(if-this-then-that)服务。您可以告诉 StackStorm 对已发生的事件做出反应,然后运行一个简单的“操作”(命令)或复杂的工作流。工作流有 2 种风格,ActionChain(他们专有的工作流 DSL)或使用 OpenStack Mistral——一种基于 YAML 的工作流引擎
StackStorm 还提供“chatops”服务,您可以在其中通过聊天平台(例如 Slack)中的事件或消息触发您的工作流程。
StackStorm 的核心命名法是;

  • 传感器是用于入站或出站集成的 Python 插件,分别接收或监视事件。当来自外部系统的事件发生并被传感器处理时,StackStorm 触发器将被发送到系统中。
  • 触发器是外部事件的 StackStorm 表示。有通用触发器(例如计时器、网络钩子)和集成触发器(例如 Sensu 警报、更新 JIRA 问题)。可以通过编写传感器插件来定义新的触发器类型。
  • 操作(Actions )是 StackStorm 出站集成。有通用操作(ssh、REST 调用)、集成(OpenStack、Docker、Puppet)或自定义操作。操作是 Python 插件或任何脚本,通过添加几行元数据使用到 StackStorm 中。操作可以由用户通过 CLI 或 API 直接调用,或者作为规则和工作流的一部分使用和调用。
  • 规则将触发器映射到操作(或工作流),应用匹配条件并将触发器有效负载映射到操作输入。
  • 工作流将动作拼接成“超级动作”,定义顺序、转换条件和传递数据。大多数自动化不仅仅是一个步骤,因此需要多个操作。工作流,就像“原子”动作一样,在动作库中可用,可以手动调用或由规则触发。
  • 包(Packs)是内容部署的单位。它们通过对集成(触发器和操作)和自动化(规则和工作流)进行分组来简化 StackStorm 可插拔内容的管理和共享。 StackStorm 社区提供了越来越多的包。用户可以创建自己的包,在 Github 上分享,或提交到 StackStorm Exchange。
  • 手动或自动操作执行的审计跟踪与触发上下文和执行结果的完整详细信息一起被记录和存储。

设计


StackStorm 由许多服务组成,它们利用消息队列(rabbit)和数据存储(mongo)来保存状态和通信。 StackStorm 也有一个 WebUI(是的,即使在免费版本中),它使您能够配置规则、运行临时操作并检查审计跟踪。


架构

architecture

与 Ansible 和 Salt 不同,StackStorm 不是为端点配置或通信而设计的。 StackStorm 有 Salt、Chef、Puppet 和 Ansible 的包,所以如果你想使用 Chef 作为代理和配置管理系统,然后利用 StackStorm 调用基于 API 的服务,如 Sensu 或 Kubernetes,这很容易实现并且显而易见。对于 Salt,你仍然有在 minion 或 master 上执行的这个概念,如果你想调用 Kubernetes API,哪个机器调用 API 没有实际意义。网络设备配置也是如此。


MongoDB 可以使用有据可查的模式进行扩展,RabbitMQ 也可以。服务本身都被设计为 HTTP/RESTful API,并且可以进行负载平衡以进行横向扩展。根据您的需要,这些角色可以压缩为单个服务器或分布在多个服务器中。


我真的很喜欢 StackStorm 可扩展性系统,它绝对是其他 2 个产品的关键优势。 StackStorm 扩展点称为包,它们是自包含的,可以存储在 Git 中并通过包级 Python 虚拟环境管理自己的依赖项。安装包时,您指定 Git URL 或 HTTP URL、(可选)凭据和 StackStorm 将下载、配置和安装包。
如果 StackStorm 是一种编程语言,它将是强类型的。对于操作,您指定所有输入的类型,对于触发器,您指定字段和类型。这使得很容易知道 3rd 方扩展将返回什么,并且是 StackStorm 独有的。
与 Salt 和 Ansible 不同,StackStorm 没有捆绑任何扩展,它们都必须单独安装,这使得部署更轻,依赖项也很轻。

在为 StackStorm 开发集成时,您可以将传感器、操作和工作流构建到一个定义中。 Salt 和 Ansible 模块是独立的。因此,如果您对 say Salt 的扩展包括信标、执行模块和状态模块,那么除了名称和作者之外,它们不共享任何内容。这在管理 pip 依赖项时可能会很麻烦。
StackStorm 通过每个包都有自己的 requirements.txt 以及描述包的目的、要求和版本的 YAML 文件来解决这个问题。您可以内联升级包,它将保留现有配置。与 Ansible 和 Salt 不同,Packs 还包含模板化配置,其中模块配置格式仅保留在文档中,因此更容易出现用户错误。此外,当开发人员没有费心记录配置选项是什么时,您通常会扫描模块代码。
另一个独特的功能是 ChatOps “别名”(聊天命令)内置在包中。因此,如果您安装 NAPALM 包作为示例,它会自动安装 NAPALM 的所有聊天命令。


企业支持


StackStorm 是 Apache-2 许可的开源产品,托管在 GitHub 上。 StackStorm 归博科所有(最近被剥离,StackStorm 部分归极进网络所有)。
如果您获得 StackStorm 许可,您将购买名为“Brocade Workflow Composer”的产品,获得附加功能以及企业级支持。我使用的生产部署已获得许可,我发现他们的支持团队响应迅速且知识渊博。您还可以获得 RBAC,您可以在其中指定谁有权运行什么的操作级别。

Brocade Workflow Composer

网络支持


如果您使用的是 Brocade VLX 或 SDX,那么您很幸运,正如您所期望的那样,它们得到了很好的支持。
2017 年 4 月,他们合并了对 NAPALM 库的支持,这是一个用于 Cisco、Juniper、Arista 和其他公司的跨平台抽象 Python 包。 您可以使用 NAPALM 集成配置路由、接口、BGP 对等互连和其他一些漂亮的功能。 Matt Oswalt(O'Reilly 网络自动化书籍的合著者)写了一篇关于进展的不错的博客。

https://youtu.be/M7Zi2HbFelQ

优势

 

  • 免费的默认 Web UI 易于使用,并且几乎不需要 Python 或 DevOps 知识。
  • ChatOps 集成是内置的,开箱即用(使用 Slack,只需部署 API 密钥)并支持许多其他聊天平台。
  • 一旦你学会了 OpenStack Mistral 真的很强大,你可以跨越多个 DevOps 工具,轻松创建分支和循环,而无需
  • Brocade Workflow Composer 是让非开发人员利用该系统的好方法


弱点

 

  • 与 Salt 和 Ansible 相比,没有可用的扩展包范围。首先检查您的系统和 API 是否可用,还要检查包中有哪些功能。
  • 工作流系统 OpenStack Mistral 的文档仍然很糟糕,YAQL 查询语法中有很多尝试和错误。


Salt


首先,Salt 是产品,SaltStack 是公司。所以当我提到 Salt 时,我指的是 Salt Open,开源版本。
Salt 有一个庞大的命名法,一开始(当我说第一次时,我指的是第一年)它可能真的让人不知所措。 Salt 有很多作用,所以通常当你听到 Salt 粉丝将它与 Ansible 进行比较时,你会得到“是的,但它做得更多”的回应。与 StackStorm 类似,这适用于和反对 Salt。一旦你知道盐矿是什么,这很明显,但如果我只是告诉你从盐矿中获取谷物,你会认为我指的是托尔金小说。


设计


Salt 诞生于分布式远程执行系统,用于在远程节点或“minions”上单独或通过任意选择标准或“目标”执行命令和查询数据。
Salt 已扩展为配置管理系统,能够在定义的状态下维护远程节点(例如,确保安装特定的包和运行特定的服务)。 Salt 中有很多组件,我确定我错过了其他组件!

  • master,运行核心服务以与 Salt Minion 通信的服务器。它还包含用于在 Minion 之间进行加密的密钥库。
  • minions,代理运行一个微型版本的 Salt,用于本地执行和与 master 的通信。
  • 引擎(engines),Salt 引擎是利用 Salt 的长期运行的外部系统进程。
  • 状态或公式(states, or formulas),包含 YAML 和模板化数据的文件以配置 Minion。模板引擎也非常灵活。它不仅限于 Jinja,还包括 chetah、genshi、mako(对于那些来自 Puppet 背景的人来说非常重要)、wempy 甚至纯蟒蛇。

可以使用谷物(grains)、支柱(pillars )或标识符(identifiers)来定位小兵(Minions )(代理或常规)。还有其他定位插件(您可以基于 SQL 查询或 KVP 存储等开发自己的插件)。

  • 谷物(grains),Salt 带有一个接口来获取有关底层系统的信息。这被称为颗粒界面,因为它提供了带有信息颗粒的盐。为操作系统、域名、IP 地址、内核、操作系统类型、内存和许多其他系统属性收集 Grain。谷物接口可用于 Salt 模块和组件,以便正确的 salt minion 命令在正确的系统上自动可用。
  • 支柱(pillars),支柱是 Salt 的接口,旨在提供可分发给 Minion 的全局值。支柱是一种自由形式的数据资源(可以是 JSON、YAML 或您需要的任何格式),可以存储在文件中,也可以存储在外部。这是 Salt 的独特属性,允许与共享数据存储有价值的其他系统(例如 ITSM 或资产注册)集成。

对于数据获取,您还可以从 minion 返回数据并将其存储在盐矿中,以用于其他任务,例如基于模板的状态配置。与 Ansible(仅支持 YAML)不同,它可以采用多种格式。


架构


Salt 的架构基于中心辐射式方法。一些非常大的部署有多主,但这种情况很少见。部分由于轻量级消息总线 ZeroMQ,主节点可以轻松扩展到数千个节点。其他部署模型是

  • 无主设置,以及
  • 等级大师(Hierarchical masters)能够使用合成器在它们之间进行通信。

master 包含状态文件,您通常会将其放入共享存储卷中。这些设置在树中,以便您可以使用目标来指定要配置的服务器组和要部署的环境/应用程序。

Salt

Salt 基于事件的系统正在使用信标。与 StackStorm 的传感器和触发系统类似,Salt 的信标将事件发送到消息总线中,然后可以在反应器中(在主节点上)进行处理。与 StackStorm 相比,反应堆中的规则引擎相当粗糙,因为您通常在触发事件的信标背后触发状态或执行命令。但是,信标在 Minion 上运行,因此如果您在服务器上检测事件,这是直接的。因为 StackStorm 和 Ansible 是无代理的,所以这是 Salt 的一个独特功能。
钍(Thorium),盐的复杂反应器在上一个版本中是实验性的,可能会在未来版本中得到支持。它增加了对事件聚合和更复杂规则的支持。


可扩展性


Salt 中的所有内容都是可扩展的,直到在 CLI 中显示执行结果的模块。这对 Salt 来说是一大优势,因为您可以轻松开发自己的更改,而无需维护主项目的并行分支。 Salt 中的每个功能也是可插拔的。
可扩展性最常见的场景是开发状态模块(描述应如何配置软件或服务)或执行模块(与 API 或系统对话的代码)。状态和执行模块都可以用相对较少的样板来编写,有很好的文档记录,并且内置了可靠的单元测试运行程序。您可以使用 PyTest 对模块进行单元测试,而无需在主机上或运行主机,以进行集成测试你应该在 Linux 上,尽管通过一些黑客攻击你可以在 OSX 上运行它们(Windows 是不可能的,就像 StackStorm 和 Ansible 一样)。
您可以维护自己的独立包,也可以直接为 GitHub 上的 Salt 项目做出贡献。为主要项目做出贡献的最大缺点是您需要等待每个发布周期,以便用户能够轻松安装您的模块。按照目前的节奏,大约每 3 到 5 个月一次,因此虽然 Salt 是“包括电池”,但它也有缺点。
Salt 还有一个包管理器,SPM,主要用于捆绑他们的配置管理(状态文件)公式。您可以使用它来打包模块以解决我将在弱点中提到的缓慢发布周期(尽管这不是很好的文档)。
盐在过去几年中发展非常迅速,并发生了一些重大变化。因此,社区开发的模块之间可能存在不一致。我还发现,虽然不是 Salt 独有的,但社区提供的模块测试不佳。

企业支持


“Salt Open”是开源版本,您可以许可 Salt Enterprise,它带有一些简洁的功能,例如:

  • 用于定位、执行、符合“高状态”以及与 LDAP 集成的 Web UI,
  • ServiceNow 集成,使您能够配置新服务器并应用来自 ServiceNow ITSM 集成的状态,
  • RBAC 与 LDAP 集成(自然),
  • “企业 API”,它将企业功能包装到 REST API 中。


网络支持


因为 Salt 依赖于消息总线,而 ZeroMQ 有许多依赖项,通常需要一个完整的 OS 网络设备管理,所以不是 Salt 的明显用途。在上一个版本中,Salt 大大改进了对“代理仆从”的支持。 Proxy minion 是一个虚拟的 minion,它是一个可以在任何地方运行的进程,以便通过 SSH、HTTP 或其他传输机制远程控制设备。它利用与常规 minion 相同的功能,但也有一些特殊性。为了避免与 Puppet 代理(它是一个中央机器,所有请求都通过它)混淆,它只是一个与您的目标设备相关联的进程,因此每个 minion 一个单独的进程。它通常是轻量级的,消耗大约 40MB 内存。您可以通过开发可在 Minion 上执行的 Python 模块来开发代理 Minion。 Salt 团队在去年的 SaltConf 上演示了这个。
目前支持的网络平台有:

  • JunOS (Juniper)
  • NXOS (Cisco)
  • Cisco NSO (Cisco’s NETCONF orchestrator)
  • NAPALM

salt_enterprise

由于 Cloudflare 的一些非常聪明的工程师,Salt 最近合并到了 NAPALM 支持中。 NSO 和 NAPALM 有相似之处,但由于 NSO 承担来自思科的许可成本,您需要考虑尽早采取哪条道路。

https://youtu.be/99jHvkVM0Dk

优势

 

  • Salt 支持基于代理和无代理(salt-ssh)
  • ZeroMQ 为大型部署提供超高性能
  • 基于代理的架构允许将信标部署在基于 Windows 或 Linux 的主机上,并允许在本地检测事件
  • 一些非常大的部署,例如LinkedIn 大规模使用
  • Salt 可以通过其强大的可扩展性轻松融入现有的数据库或 API 集。


弱点

 

  • 对于快速移动的环境,内核中内置的可扩展性发布太少
  • 模块不能干净地声明自己的依赖项,这意味着您必须管理单个虚拟环境和 pip 依赖项


结论


事件驱动与否?


这是这 3 款产品最大的不同,Salt 和 StackStorm 都有事件驱动的故事。 StackStorm 具有您可以编写的服务(传感器)和可以引发的强类型事件以及复杂的规则引擎。 Salt 有信标,可以在代理和中央主机上运行的服务,如果你想检测本地机器上的事件,这是一个独特的功能。 Ansible 的开源版本不允许(也不会尝试)允许您响应事件。


社区支持


我见过网络供应商专门针对 Ansible 开发模块,而对于其他平台(除了用于 StackStorm 的 Brocade),他们都是社区贡献的。 Ansible 当然对网络平台有最广泛的支持。虽然,随着 NAPALM 和 NSO 被引入 StackStorm 和 Salt,这改变了事情,因为它们都支持 Arista、JunOS(瞻博网络)、Cisco APIC-EM、NXOS 等。


开始的时间


Ansible 的优势在于最少的配置量(基本没有)。它在网络领域的流行可能是由于网络管理员习惯于使用 CLI 之类的东西来管理远程设备而无需部署任何额外的服务器来运行软件的简单性和熟悉性。如果您有很多小的、孤立的站点(例如商业分支机构),那么您应该考虑您的架构是否会崩溃。我的雇主为一些大型连锁超市管理网络,当农村地区的商店连接不可靠时,我会犹豫是否拥有一个集中的主人。

数据配置存储


Salt 的独特之处在于它的密钥库都是可插拔的。如果您想从 Hashicorp Vault 获取密码或密钥,这很容易。如果您想将谷物数据存储在 SQL 数据库中,它同样是开箱即用的。考虑访问或输入您的目标数据需要哪些其他系统和平台。


安全


比较 Ansible 和 Salt,Salt 有自己的密钥库用于代理通信,而 Ansible 使用 SSH 进行传输。管理不善的 Ansible 环境通常是存储在管理员笔记本电脑上的一堆私钥(请不要这样做)。 Salt 为模板、状态或谷物中的安全数据提供了独特的功能,这些数据能够存储在外部安全数据存储中。 StackStorm 确实将数据保存在 MongoDB 中,在您投入生产之前,您的安全团队当然需要对其进行审核。


培训


除非你想成为这个平台的唯一维护者,否则你需要教育一些同事。 Salt 和 Ansible 都出版了详细的书籍,而 StackStorm 没有。 Salt 和(RedHat)Ansible 提供培训解决方案,几乎完全在美国,StackStorm 还没有。 Salt 和 Ansible 有关于 PluralSight 的课程,但它们非常基础。


许可


Salt 和 StackStorm 都是 Apache-2 许可的,Ansible 是 GPLv3。如果您不太熟悉 OSS 许可,我推荐“TLDR Legal”的网站。 SuSE 使用 Salt 作为示例来构建系统管理产品,部分原因是其 OSS 许可的灵活性。


技能


有趣的是(尽管我非常关注这一点),Ansible 获得了全球网络管理员和 DevOps 工程师的良好思想分享。你肯定会发现招聘 Ansible 工程师比 Salt 或 StackStorm 容易得多。但是 DevOps 工程师仍然像母鸡一样罕见,因此无论平台如何,您都将支付高昂的费用。


我应该选择哪种胶水?


请尝试至少 2 个平台并做出明智的决定。
我之前曾在博客中讨论过这一点,但是使用 DevOps 工具,人们可以在学习工具的同时发现自动化的奇迹,然后虔诚地坚持使用该工具。


就像第一次发现巧克力的孩子一样,您不应该只相信那短暂的快乐纯粹是吉百利的功劳。

原文:https://medium.com/@anthonypjshaw/ansible-v-s-salt-saltstack-v-s-stacks…

本文:https://jiagoushi.pro/node/1651

SEO Title
Ansible v.s. Salt (SaltStack) v.s. StackStorm

Linux

Chinese, Simplified
SEO Title
Linux

CentOS 7 在 Apache 服务器上安装 Let's Encrypt SSL

Chinese, Simplified

先决条件
以 sudo 身份访问服务器。
正确配置的域和虚拟主机。
如果您具备这些先决条件,那么让我们开始吧。

目录

  • 安装依赖
  • 安装 Certbot——让我们加密客户端
  • 生成 SSL 证书
  • 设置自动续订
  • 检查证书状态
  • 删除 Certbot 证书

第 1 步:安装依赖项


要安装 Certbot,我们需要安装 EPEL 存储库和 mod_ssl。 运行此命令以安装两者:

sudo  yum install -y epel-release mod_ssl


第 2 步:安装 Certbot——让我们加密客户端


从 EPEL 存储库,让我们安装 Certbot 客户端:

sudo yum install -y python-certbot-apache


第 3 步:生成 SSL 证书


我们有必要的模块来生成 Let's Encrypt SSL。 要为单个域生成证书,请运行以下命令:

sudo certbot --apache -d example.com


要为多个域或子域生成 SSL,请运行以下命令:

sudo certbot --apache -d example.com -d www.example.com


此处,example.com 是基本域。

您还可以通过选择域名来生成 SSL 证书。为此,请运行以下命令以显示所有托管域:

sudo certbot --apache


选择一个选项并根据需要运行该命令。安装成功后,您将看到类似于此消息的消息:

重要笔记:

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
   Your cert will expire on 2019-10-24. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le


第 4 步:设置自动续订


我们知道 Let's Encrypt 证书的有效期为 90 天。但是我们可以很容易地更新证书。只需在到期日期之前运行此命令:

sudo certbot renew


我们还可以设置一个 cronjob 来自动更新。打开定时任务:

crontab -e


然后添加这一行:

0 0 * * 1 /usr/bin/certbot renew >> /var/log/sslrenew.log


第 5 步:检查证书状态


我们已经成功安装了 Let's Encrypt SSL。现在让我们通过访问此 URL 来检查 SSL 证书的状态:

https://www.ssllabs.com/ssltest/analyze.html?d=example.com


第 6 步:删除 Certbot 证书


要删除证书,我们必须运行以下命令:

# 选择域名


sudo certbot delete

# 直接分配域名


sudo certbot delete --cert-name example.com


 文章结束了。谢谢阅读

原文:https://shouts.dev/centos-7-install-lets-encrypt-ssl-on-apache-server

本文:https://jiagoushi.pro/centos-7-install-lets-encrypt-ssl-apache-server

SEO Title
CentOS 7 Install Let’s Encrypt SSL on Apache Server

【Linux】CentOS Linux 8将于2021年结束,并将重点转移到CentOS Stream上

Chinese, Simplified

CentOS Linux 8 will end at 2021: Project shifts focus to CentOS Stream

 

CentOS是社区企业操作系统的首字母缩写,它是RHEL(红帽企业Linux)的100%重建。虽然RHEL需要花钱,但CentOS提供了一个免费的社区支持的企业Linux发行版。那些擅长Linux并且不想支付RHEL支持费用的开发人员和公司总是选择CentOS来节省资金并获得企业级的软件。然而,免费的旅程结束了。红帽公司宣布,作为RHEL 8的重建版本,CentOS Linux 8将于2021年结束。CentOS Stream在那之后继续,作为红帽企业Linux的上游(开发)分支。

CentOS项目历史

我们在2004年5月看到了CentOS的第一个版本,称为CentOS版本2,它是从RHEL 2.1AS (advance server)派生出来的。它在Linux爱好者、web托管公司、开发人员和HPC社区中迅速走红。CentOS免费提供企业级软件,提供自我支持,社区支持由电子邮件邮件列表或在线论坛驱动。当您不再需要支持或培训合同时,这是节省昂贵的RHEL合同费用的好方法。

什么是CentOS Stream?

CentOS Stream在Fedora和RHEL之间。换句话说,CentOS Stream是RHEL的滚动发行版。它充当Fedora和RHEL之间的网关:

Upstream ➡️ Downstream ➡️ RHEL

所以我们有:

Fedora Linux ➡️ CentOS Stream ➡️ RHEL

CentOS项目将重点转移到CentOS Stream,CentOS Linux 8将于2021年结束

从公告邮件中:

CentOS项目的未来是CentOS Stream,在接下来的一年里,我们将把重点从CentOS Linux,红帽企业Linux (RHEL)的重建,转移到CentOS Stream,它跟踪当前RHEL发行版之前的情况。作为RHEL 8的重建版本,CentOS Linux 8将于2021年底结束。CentOS Stream在那之后继续,作为红帽企业Linux的上游(开发)分支。当CentOS Linux 8 (RHEL8的重建)结束时,您最好的选择是迁移到CentOS Stream 8,它是CentOS Linux 8的一个小改进,并且有像传统CentOS Linux版本一样的定期更新。如果您在生产环境中使用CentOS Linux 8,并且担心CentOS Stream将不能满足您的需要,我们鼓励您联系红帽有关选项。

CVE在CentOS Stream中将如何处理?

安全问题在当前RHEL版本中解决后,将在CentOS Stream中更新。显然,在禁运解除之前,禁止发布的安全文件不能公开发布。虽然没有任何用于计时的SLA,但红帽工程师将根据这些版本构建和测试其他包。如果它们没有滚入更新,则它们构建的其他软件可能会受到影响,因此需要重做。因此,获得这些更新是他们的既得利益,这样就不会影响到他们的其他版本,获得安全更新也不会有任何问题。

换句话说,CentOS Streams的用户将在所有人之前测试RHEL并报告漏洞,但是在RHEL解决之前,他们不会得到安全更新。非常棘手的情况。

这是否意味着CentOS Stream现在是RHEL的BETA测试平台?

按照常见问题解答:

不。CentOS Stream将在RHEL之前得到修复和特性。一般来说,我们期望CentOS Stream比RHEL有更少的bug和更多的运行时特性,直到这些包进入RHEL的发行版。

如果您使用CentOS进行CI,则没有选择,因为您不能使用RHEL开发人员许可证。另外,请注意CentOS Stream有时会有不同的ABI/API,因此您不能在本地测试或构建EPEL包。

CentOS社区能继续开发/重建CentOS linux吗?

Red Hat说他们我们不会把硬件、资源,或要求志愿者努力努力,我们也不会允许CentOS品牌用于这样一个项目,因为他们觉得它稀释我们正在试图做的重新关注CentOS Stream。也就是说,代码是开源的,他们不会试图阻止任何人选择使用它或从代码构建自己的包。

对CentOS 7没有影响

CentoS 7将在RHEL 7剩余的生命周期内继续生产。所以对CentOS 7用户没有影响。

结论

我认为这是红帽子的错误举动。CentOS的主要优点是提供了与RHEL 100%的二进制兼容性。在工作中,我们主要使用CentOS进行测试,因为我们的目标是RHEL,但是这样可以节省很多钱。CentOS是我们针对MySQL、PHP、Nginx、Java和许多其他应用程序的“严肃的测试平台”。一旦应用程序准备就绪,我们将把它部署到RHEL 8集群上。当然,我们可以获得RHEL开发人员订阅,但只有一个免费的Red Hat开发人员订阅可以添加到用户帐户这样的目的。因此,如果你有七个开发者,另外六个开发者可以在developers.redhat.com上创建他们自己的用户账户。我们必须处理额外的账目。因此,如果开发人员想要一个免费的RHEL,下一个最好的选择可能是Oracle Linux。

许多用户将不会高兴。我们可能也会看到一个新的分叉,但只有时间会告诉我们答案。其他Linux发行版,如Ubuntu或Debian LTS也会有很多新用户。

红帽从大规模的CentOS社区中获益良多,这种改变是不必要的。这是我诚实的意见。你觉得怎么样?您是否受到了这个新变化的影响,如果是的话,哪个Linux发行版会选择取代CentOS 8?

 

本文:http://jiagoushi.pro/node/1375

讨论:请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【1110777】

SEO Title
CentOS Linux 8 will end in 2021 and shifts focus to CentOS Stream

【Linux】这些是用于编程的最佳Linux发行版

QQ群

视频号

微信公众号

知识星球

Chinese, Simplified

您是程序员、工程师还是系统管理员,希望最大限度地利用您的计算机?然后,您需要最好的Linux发行版进行编程。我们选择Fedora是因为它突破了Linux的限制,拥有最新的开源软件。

我厌倦了解释Linux没有那么难。事实上,如果你在Android手机或Chromebook上阅读这篇文章,恭喜你!您使用的是Linux,您可能不太了解它。但还有一些Linux发行版需要专业知识才能充分利用

你为什么要找麻烦?因为你是一名程序员、工程师或系统管理员,希望从Linux中获得最大的收益。或者,你是一个超级用户,你想尽可能地推动你的电脑。如果是你,那么这些就是你的发行版

Fedora

适合编程/程序员的最佳Linux发行版

 

fedora
 

优点和缺点

赞成的意见

  • 易于安装和设置
  • 优秀的开发人员门户网站,提供专门的指南

缺点

  • 更新到新版本可能很困难

 

功能:

开发人员门户和工具|由最新的Linux内核支持|集成开发环境

你知道红帽的社区Linux发行版Fedora将是我名单上的第一个,也是我们的最佳总体选择。它是推动Linux极限的主流发行版。它由最新的Linux内核和最新的开源软件提供支持。

特别是,Fedora是程序员选择的Linux。Linus Torvalds在开发工作中使用Fedora,这一数字不亚于Linus Torvalds。我需要说更多吗?

然而,有时候,当你在运行一个前沿发行版时,你可以削减自己。Fedora也被称为“前沿Linux”,这是有原因的。

另一方面,Fedora易于安装和设置。你不需要成为Linux专家就可以开始使用它

对于程序员来说,Fedora还拥有一个优秀的开发者门户。它提供了开发命令行、桌面、移动和web应用程序的专用指南

Fedora开发者门户网站还提供了一个开发Arduino和Raspberry Pi等硬件设备的优秀指南。最后但并非最不重要的是,它附带了顶级集成开发环境(IDE)Eclipse for Java、C/C++和PHP以及Vagrant等开发工具,这是一种用于创建可复制、可移植容器或基于虚拟机(VM)的开发环境的工具。

除非您正在开发Debian/Uubuntu系列程序,否则Fedora应该是您开发操作系统的首选。对于该组的开发人员,我推荐最新版本的Ubuntu

 

Arch Linux/Manjaro Linux

用于编程的最佳Linux发行版,可对桌面进行绝对控制

 

arch-linux-manjaro-linux
 

优点和缺点

赞成的意见

  • 完全自定义桌面
  • 易于切换操作系统档位

缺点

  • 定制对某些人来说可能是压倒性的

 

功能:

同时支持多个内核|包括GNOME、KDE Plasma和XFCE

您是否希望设置一个Linux桌面,使其正常工作并看起来完全符合您的要求?如果是你,那么Arch Linux值得你关注。有了Arch,一切都在你的控制之下。这既是好消息也是坏消息

虽然Arch的口号是“保持简单”,但用户眼中的简单。对于第一个“桌面”是伯恩外壳的人来说,这并不难。但是,对于那些没有使用命令行长大的人来说,这是另一回事。

你看,Arch只有一个命令shell。这完全取决于您将使用哪种桌面环境,以及如何进行定制。通过汗水和辛劳,您可以获得满足您的确切要求和需求的产品。这不容易。即使有其优秀的ArchWiki文档网站的帮助,您也需要做很多工作。但是,当你完成后,你会有一个独特的桌面来调用你自己的桌面。

或者,如果这听起来工作量太大,您可以使用Manjaro Linux。这个发行版从安装和运行Arch中消耗了大量的心血、汗水和眼泪。它有三个主要的桌面版本:GNOME、KDE Plasma和XFCE。 

同时,如果你想切换Linux内核,Manjaro是少数几个可以轻松切换操作系统的发行版之一。它同时支持多个内核。您只需重新启动系统,在启动菜单中进行选择,然后返回桌面,并在下面运行一个新内核。 

这是大多数人都想做的吗?没有。但是,如果你真的想测试Linux内核,那么Manjaro是适合你的

 

Gentoo/Sabayon Linux

用于编程的最佳基于源代码的Linux发行版

 

gentoo-sabayon-linux
 

优点和缺点

赞成的意见

  • 完全控制桌面

缺点

  • 不易使用

 

功能:自定义|功能强大|使用源代码

你真的,真的想用Linux深入研究吗?如果是这样,那么基于源代码的发行版Gentoo适合您。对于初学者来说,Gentoo没有安装程序。正如其开发人员所说,“你是安装者。”这意味着,“你可以应用你想要的所有定制”——一旦完成,你就吸收了Gentoo手册。除非你是Gentoo的专家用户,否则我建议你在另一台电脑上保存一本手册。你将需要你所能得到的一切帮助来让Gentoo开始运转。

完成后,您还需要了解Portage软件包系统的详细信息。与几乎所有其他Linux发行版使用二进制软件打包系统(如Red Hat的RPM和Debian的APT)不同,Portage是基于源代码的。因此,例如,如果你想在Portage中安装一个程序,你实际上是在你的机器上编译应用程序的源代码。您还可以使用USE标志自定义来“编辑”源代码。

容易做吗?见鬼,不!但如果你想绝对控制桌面上的内容,Gentoo适合你。

但是,如果你想要很大的力量,但没有那么多的工作?然后,就像Arch和Manjaro一样,您可以将Sabayon Linux与Gentoo一起使用。该发行版的开发人员的目标是通过以优雅的格式提供最新的开源技术,提供最佳的“开箱即用”用户体验。在Sabayon,一切都应该正常工作。我们提供了一个稳定可靠的前沿操作系统

本质上,Sabayon为您做出大部分Gentoo设置决策。你仍然可以得到很多控制,但你不必转动每个旋钮和拨动每个开关就能得到一个工作系统。 

展望未来,Sabayon将更名为MoaccinoOS。这与Gentoo的主要区别在于它使用了新的基于容器的包装系统Luet。这仍然是测试版,我只能向有经验的开发人员和用户推荐这个版本。

 

Kali Linux

为安全专家及其黑客敌人编程的最佳Linux发行版

 

kali-linux
 

优点和缺点

优点

  • 由一家安全公司建造
  • 安装和设置很简单

缺点

  • 默认软件包不太好

 

功能:专为黑客设计|基于Debian构建|易于设置和安装

现在,换一种不同的方式。Kali Linux是一个为渗透测试或黑客攻击而设计的Linux发行版。感谢Mr。机器人,Kali Linux是最著名的黑客发行版

Kali Linux是安全公司Offensive security的开发人员的作品。它建立在Debian之上。历史上,它可以追溯到基于Knoppix的数字取证和渗透测试发行版BackTrack。

虽然安装和设置Kali与设置任何Debian发行版一样简单,但它的默认软件包却是另一回事。例如,默认情况下,没有为您的默认办公套件提供LibreOffice,也没有为电子邮件客户端提供Thunderbird。相反,它配备了OWASP ZAP等安全程序,用于针对安全问题攻击网站;SQLMAP,自动检测和利用SQL注入漏洞;以及THC Hydra,一种流行的密码破解器

现在Kali Linux不能把你变成黑客或安全专家。要做到这一点,你真的必须知道计算机、编码和安全是什么。它只是为您提供了入门所需的工具和专家需求

如果你只是想伪装成黑客,那就从黑客打字机开始吧。享受

 

系统救援

最好的Linux发行版,用于编程,让死亡的PC重获新生

 

systemrescue
 

优点和缺点

优点

  • 设计用于修复损坏的计算机
  • 附带有用的程序

缺点

  • 并非永久性操作系统
  • 不易使用

 

功能:从USB驱动器、DVD驱动器或CD驱动器启动|包括GNU Parted、ddrescue和rsync |重新启动旧的和过时的计算机

破坏系统,或者检查它们是否可以被破坏的另一面是修复已经损坏的系统。这些修复Linux发行版中最好的是SystemRescue。这个操作系统,也被称为SystemRescueCD,它可以让你了解它有多旧,是用来修复损坏的计算机的。

这是我和其他Linux专家在遇到Windows安装失败和硬盘损坏时需要帮助的发行版。它并不是一个永久的操作系统。相反,您可以从USB驱动器、DVD驱动器,或者,是的,甚至现在也可以从CD驱动器启动它。一旦启动,你就可以用它来探索一台半死不活的电脑,并尝试让它复活。

它不容易使用。就像Kali一样,它为你提供了完成工作所需的工具。在这种情况下,它附带了GNUParted等程序,用于操作磁盘分区和文件系统;ddrescue是一种数据恢复工具,通过从损坏的存储设备复制块级别的数据来工作;rsync是一个程序,用于通过本地网络将数据从故障驱动器克隆到另一台稳定的计算机。 

这些工具都不容易。我建议您在尝试救援故障系统之前,先阅读SystemRescue手册。也就是说,一旦你知道你在做什么,你就可以期待朋友和家人在他们的Windows电脑出现严重问题时能听到他们的消息

现在在System Rescue查看现在在SourceForge查看

最适合编程的Linux发行版是什么?

基于我们对功能、工具和可用性的专家分析,Fedora是最适合编程的Linux发行版。然而,您可能想要/需要一些不同的东西,因此以下是我们的首选比较:

Linux 发行版

设计用于

随附

Fedora

编程和程序员

Eclipse for Java, C/C++, PHP, and Vagrant

Arch Linux/Manjaro Linux

完整的桌面定制

GNOME, KDE Plasma, and XFCE

Gentoo/Sabayon Linux

控制桌面

N/A

Kali Linux

安全专业人员

OWASP ZAP, SQLMAP, and THC Hydra

SystemRescue

陈旧或过时的计算机 

GNU Parted, ddrescue, and rsync

哪个Linux发行版适合您?

嗯,这真的取决于你的技能水平、知识以及你想从桌面上得到什么。在选择这些选项时,请考虑这些因素。

选择此。。。

如果你想。。。

Fedora

最佳整体选项

Arch Linux, Manjaro Linux

控制桌面

Gentoo/Sabayon Linux

基于源代码的选项

Kali Linux

为黑客设计的东西

SystemRescue

让一台死去的电脑复活

我们是如何选择这些桌面Linux选项的?

我已经运行Linux 29年了。Linux已经有30年的历史了。我对这个操作系统了如指掌。在那之前,我已经对第7版Unix咬过牙了。换句话说,我对Linux有一点了解。我在这里给出的意见是基于所有这些经验以及我多年来认识的许多Linux内核开发人员和发行版程序员的经验。也就是说,如果有任何错误,都是我的

我怎样才能成为Linux专家?

有很多方法可以学习如何成为Linux用户。一个很好的入门方法是Linux基金会的免费在线课程Linux简介。成为Linux专家需要更多

如果你想以Linux为生,我建议你获得Linux基金会认证系统管理员(LFCA)认证。从以下课程开始:Linux系统管理基础(LFS201)和Linux网络和管理(LFS211)

或者,如果您确定您的未来在Red Hat Enterprise Linux(RHEL),请从Red Hat System Administration I(RH124)和Red Hat System Administration II(RH134)开始。您的目标是成为Red Hat认证系统管理员(RHCSA)

如果您已经熟悉Linux,也可以通过RHCSA快速通道课程(RH199)快速进入RHCSA

为什么这样做?当然,要靠Linux谋生。根据Payscale的数据,一个Linux系统管理员平均每年可以赚76880美元。那不是鸡饲料。认证可以帮助你从其他申请人中脱颖而出

Linux上最好的书是什么?

没有什么比使用Linux更好的了,但有一些书可以帮助您掌握它。

学习Linux的最好方法是使用它,并使用“man”命令,如RTF

也就是说,还有一些有用的书可以让你从对Linux了解一二的人变成真正的专业人士。我有一句话要提醒你:一定要阅读这些书中的最新版本。一本让你快速了解init如何运行Linux实例的书对你没有任何好处,因为它基本上已经被systemd取代了

以下是我的一些最爱:

  • Linux如何工作,第三版:每个超级用户都应该知道的第三版。布莱恩·沃德(Brian Ward)的这本书涵盖了历史基础知识及其现代等效知识。因此,例如,除了涵盖Linux磁盘分区之外,它还涵盖逻辑卷管理器(LVM)。 
  • 威廉·肖特斯(William Shotts)的《Linux命令行:完整介绍第1版》提供了它所承诺的一切。在您了解了这一点之后,您现在只知道如何绕过Bash shell(最流行的Linux shell),而是如何使用sed、grep和awk等强大的shell程序的基础知识。曾经有一段时间,我通过掌握最后三人组来谋生
  • Richard Blum和Christine Bresnahan编写的Linux命令行和Shell脚本圣经第四版。掌握了Shotts书中的一切?好了,那么,你准备好继续阅读这本巨著了。这一新版本于2021年初出版,将带您了解基础知识,并从基础知识转向更高级的主题。它通过简单易懂的教程和示例实现了这一点。
  • 《Linux食谱:Linux用户和系统与网络管理员的基本技能》,Carla Schroder第二版。卡拉知道她的Linux。她做这件事的时间几乎和我一样长。这一对她早期经典的新更新带来了商品。本质上,如果你是Linux超级用户或系统管理员,它的食谱是一些最常见的情况下的小诀窍。我强烈推荐这本书,风格有趣。

什么是基本的Linux网站?

如果你真的想了解Linux,你想读我写过的所有东西……嗯,也许不是。说真的,如果你是一个真正的Linux专业人士,以下是你必须保留书签的网站。

要真正了解Linux内核的情况,您必须关注Linux内核邮件列表(LKML)。注意,我没有说要读。我不确定任何人真的能读到列表中的所有内容。它的信息量太大了。但是,随着你积累了经验,你将能够把小麦和谷壳分开。例如,Linus Torvalds发布的任何内容都值得一看,这是一个安全的赌注

我建议通过阅读LKML的常见问题解答来了解LKML。这将使人们更容易理解正在发生的事情。

如果这对你来说太多了——比如,我不知道你是否有生活或其他什么——你可以订阅LWN.net。有很多Linux新闻网站,但只有一个LWN。LWN由Linux内核维护者JonCorbet运行,深入了解Linux内核、开源软件和编码的细节。例如,我可以告诉您最新的Fedora版本;LWN将告诉你Fedora社区关于是否应该在开发发行版时使用非免费Git伪造的争论

不过,让我们假设,您只想了解一般的Linux新闻,而不是核心技术和编程信息。如果你是这样的话,聚合网站LinuxToday在收集Linux新闻、功能和最新教程方面做得很好。在这里,我要补充一点,你还可以找到我的许多故事的链接。 

你想知道你的新处理器是如何与Linux一起工作的吗?那么Phoronix是给你的。本网站涵盖内核新闻,但最著名的是它对最新Linux发行版和硬件的详细报告和基准测试。因此,如果您想了解Linux对英特尔软件保护扩展(SGX)的当前支持状态,或者了解Linux和Mesa驱动程序在Intel Core i5 12600K/UHD Graphics 770上的比较,以及它们在原始性能方面的相互比较,这里就是您的网站

最后,对于那些想了解Linux发行版的人,您可以选择DistroWatch。它跟踪每一个——我指的是每一个Linux发行版。据我统计,目前大约有600个发行版,其中大部分仍在积极开发中。这是跟踪他们所有人的地方。

什么是最轻量级的Linux发行版?

如果您正在寻找在旧计算机上运行的Linux版本,那么您应该考虑Absolute Linux。它允许您创建一个简单而不显眼的桌面,同时仍然提供预加载的基本程序,如Firefox用于web浏览,LibreOffice用于文字处理和创建电子表格。

Kali Linux发行版是否带有预装程序?

Kali Linux没有Firefox或LibreOffice之类的程序来帮助您开始浏览网页或起草报告。然而,它确实配备了许多安全工具,如Aircrack ng,以实现更安全的网络浏览和尸检,从而使您的Kali Linux桌面更容易运行其他开源程序和软件

是否有其他Linux桌面选项可供考虑?

以下是需要考虑的几个其他产品:

 

opensuse

openSUSE

View now at openSUSE

 

ubuntu

Ubuntu

View now at Ubuntu

 

linuxmint

LinuxMint

View now at Linuxmint

本文地址
https://architect.pub/these-are-absolute-best-linux-distros-programming
SEO Title
These are the absolute best Linux distros for programming

【基础设施】什么是Multipass?

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

What is Multipass?

Multipass是一款适用于Linux、Windows和macOS的轻量级虚拟机管理器。它是为那些想要一个全新的Ubuntu环境的开发人员设计的,只需一个命令。它在Linux上使用KVM,在Windows上使用Hyper-V,在macOS上使用QEMU,以最小的开销运行虚拟机。它还可以在Windows和macOS上使用VirtualBox。Multipass将为您获取图像并使其保持最新。

由于它支持云初始化的元数据,您可以在笔记本电脑或工作站上模拟小型云部署。

Project Status

Service Status
CI Build Status
Snap Build Status
Codecov Codecov Status

Install Multipass

On Linux it's available as a snap:

sudo snap install multipass

For macOS, you can download the installers from GitHub or use Homebrew:

# Note, this may require you to enter your password for some sudo operations during install
# Mac OS users may need to disable their firewall to launch a multipass instance successfully
brew install --cask multipass

On Windows, download the installer from GitHub.

Usage

Find available images

$ multipass find
Image                       Aliases           Version          Description
core                        core16            20200213         Ubuntu Core 16
core18                                        20200210         Ubuntu Core 18
16.04                       xenial            20200721         Ubuntu 16.04 LTS
18.04                       bionic,lts        20200717         Ubuntu 18.04 LTS
20.04                       focal             20200720         Ubuntu 20.04 LTS
daily:20.10                 devel,groovy      20200721         Ubuntu 20.10

Launch a fresh instance of the current Ubuntu LTS

$ multipass launch ubuntu
Launching dancing-chipmunk...
Downloading Ubuntu 18.04 LTS..........
Launched: dancing chipmunk

Check out the running instances

$ multipass list
Name                    State             IPv4             Release
dancing-chipmunk        RUNNING           10.125.174.247   Ubuntu 18.04 LTS
live-naiad              RUNNING           10.125.174.243   Ubuntu 18.04 LTS
snapcraft-asciinema     STOPPED           --               Ubuntu Snapcraft builder for Core 18

Learn more about the VM instance you just launched

$ multipass info dancing-chipmunk
Name:           dancing-chipmunk
State:          RUNNING
IPv4:           10.125.174.247
Release:        Ubuntu 18.04.1 LTS
Image hash:     19e9853d8267 (Ubuntu 18.04 LTS)
CPU(s):         1
Load:           0.97 0.30 0.10
Disk usage:     1.1G out of 4.7G
Memory usage:   85.1M out of 985.4M

Connect to a running instance

$ multipass shell dancing-chipmunk
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-42-generic x86_64)

...

Don't forget to logout (or Ctrl-D) or you may find yourself heading all the way down the Inception levels... ;)

Run commands inside an instance from outside

$ multipass exec dancing-chipmunk -- lsb_release -a
No LSB modules are available.
Distributor ID:  Ubuntu
Description:     Ubuntu 18.04.1 LTS
Release:         18.04
Codename:        bionic

Stop an instance to save resources

$ multipass stop dancing-chipmunk

Delete the instance

$ multipass delete dancing-chipmunk

It will now show up as deleted:

Name                    State             IPv4             Release
snapcraft-asciinema     STOPPED           --               Ubuntu Snapcraft builder for Core 18
dancing-chipmunk        DELETED           --               Not Available

And when you want to completely get rid of it:

$ multipass purge

Get help


multipass help
multipass help <command>

Get involved!

Here's a set of steps to build and run your own build of Multipass. Please note that the following instructions are for building Multipass for Linux only. These instructions do not support building packages for macOS or Windows systems.

Build Dependencies

cd <multipass>
apt install devscripts equivs
mk-build-deps -s sudo -i

Building

cd <multipass>
git submodule update --init --recursive
mkdir build
cd build
cmake ../
make

Running Multipass daemon and client

First, install multipass's runtime dependencies. On amd64 architecture, you can achieve that with:

sudo apt update
sudo apt install libgl1 libpng16-16 libqt6core6 libqt6gui6 \
    libqt6network6 libqt6widgets6 libxml2 libvirt0 dnsmasq-base \
    dnsmasq-utils qemu-system-x86 qemu-utils libslang2 iproute2 \
    iptables iputils-ping libatm1 libxtables12 xterm

Then run multipass's daemon:

sudo <multipass>/build/bin/multipassd &

Copy the desktop file multipass clients expect to find in your home:

mkdir -p ~/.local/share/multipass/
cp <multipass>/data/multipass.gui.autostart.desktop ~/.local/share/multipass/

Optionally, enable auto-complete in bash:

source <multipass>/completions/bash/multipass

Finally, use multipass's clients:

<multipass>/build/bin/multipass launch --name foo  # CLI client
<multipass>/build/bin/multipass.gui                # GUI client
本文地址
https://architect.pub
SEO Title
What is Multipass?

【虚拟化】扩展多路径虚拟机磁盘(设备上没有剩余空间)

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

最近,我的一台多路径虚拟机上的空间用完了。我决定在这里写下扩展虚拟机磁盘大小的步骤。

请考虑下面的多路径虚拟机列表:

kenneth@laptop:~$ multipass list

Name                    State             IPv4             Image
altruistic-impala       Running           172.17.244.151   Ubuntu 22.04 LTS
awx                     Stopped           --               Ubuntu 22.04 LTS
database                Stopped           --               Ubuntu 22.04 LTS
haproxy                 Stopped           --               Ubuntu 22.04 LTS

The VM named altruistic-impala is the one concerned by the disk expansion. It has the following specs:

kenneth@laptop:~$ multipass info altruistic-impala

Name:           altruistic-impala
State:          Running
IPv4:           172.17.244.151
Release:        Ubuntu 22.04.3 LTS
Image hash:     870bd58b5c1e (Ubuntu 22.04 LTS)
CPU(s):         1
Load:           0.02 0.03 0.00
Disk usage:     7.6GiB out of 7.6GiB
Memory usage:   180.4MiB out of 892.2MiB
Mounts:         --

As you can see above, the VM has a 7.6GiB disk, used at 100% of its capacity.

I will expand the disk size to 32G (feel free to put with the desired size you want):

kenneth@laptop:~$ multipass stop altruistic-impala 
kenneth@laptop:~$ multipass set local.altruistic-impala.disk=32G  
kenneth@laptop:~$ multipass start altruistic-impala 

Note: Substitute altruistic-impala in all the commands of this article with the name of your target VM.

在这一点上,我应该完成。根据Multipass文档,以上步骤就足够了。虚拟机磁盘大小应该已经扩展,根分区的大小应该已经调整。但就我而言,我得到了一个惊喜:之前的说法部分属实。调整大小操作需要一小部分可用空间。

我为什么这么说?

因为我发现,如果您的虚拟机磁盘在进行扩展时没有剩余空间,磁盘大小会发生变化,但根分区不会自动调整大小。那么修改将不会反映在操作系统中。因此,在扩展磁盘之后,我需要手动扩展主分区,并从VM中扩展文件系统。如果你也处于同样的情况,请阅读。

您可以在VM上使用lsblk命令,如下所示进行验证:

kenneth@laptop:~$ multipass exec altruistic-impala -- lsblk

NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0     7:0    0  63.4M  1 loop /snap/core20/1974
loop1     7:1    0 111.9M  1 loop /snap/lxd/24322
loop2     7:2    0  53.3M  1 loop /snap/snapd/19457
sda       8:0    0    32G  0 disk
├─sda1    8:1    0   7.9G  0 part /
├─sda14   8:14   0     4M  0 part
└─sda15   8:15   0   106M  0 part /boot/efi
sr0      11:0    1    52K  0 rom

我们可以看到,sda磁盘大小已成功地从8G增加到32G。但它的主分区sda1安装在/仍然显示7.9G的大小。我们需要调整分区大小以利用所有可用空间。

让我们进入altruistic-impala的shell:

kenneth@laptop:~$ multipass shell altruistic-impala

From that shell:

ubuntu@altruistic-impala:~$ sudo parted /dev/sda

GNU Parted 3.4
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) resizepart                                                
Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 50331648 blocks) or continue with
the current setting? 
Fix/Ignore? Fix                                                           
Partition number? 1                                                       
Warning: Partition /dev/sda1 is being used. Are you sure you want to continue?
Yes/No? Yes                                                               
End?  [8590MB]? 100%                                                      
(parted) quit
Information: You may need to update /etc/fstab.

We also need to resize the filesystem:

ubuntu@altruistic-impala:~$ sudo resize2fs /dev/sda1
  
resize2fs 1.46.5 (30-Dec-2021)
Filesystem at /dev/sda1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 4
The filesystem on /dev/sda1 is now 8360187 (4k) blocks long.

And now we’re done! We check it out:

ubuntu@altruistic-impala:~$ lsblk
                                         
NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
fd0       2:0    1     4K  0 disk 
loop0     7:0    0  53.3M  1 loop /snap/snapd/19457
loop1     7:1    0  63.4M  1 loop /snap/core20/1974
loop2     7:2    0 111.9M  1 loop /snap/lxd/24322
sda       8:0    0    32G  0 disk 
├─sda1    8:1    0  31.9G  0 part /
├─sda14   8:14   0     4M  0 part 
└─sda15   8:15   0   106M  0 part /boot/efi
sr0      11:0    1    52K  0 rom

The /dev/sda1 partition is now used at 25% against 100% at the beginning of this write-up:

ubuntu@altruistic-impala:~$ df -h

Filesystem      Size  Used Avail Use% Mounted on
tmpfs            96M  5.7M   90M   6% /run
/dev/sda1        31G  7.6G   24G  25% /
tmpfs           476M     0  476M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/sda15      105M  6.1M   99M   6% /boot/efi
tmpfs            96M  4.0K   96M   1% /run/user/1000

It corresponds to 7.6GiB used out of 30.9GiB:

kenneth@laptop:~$ multipass info altruistic-impala

Name:           altruistic-impala
State:          Running
IPv4:           172.17.244.151
Release:        Ubuntu 22.04.3 LTS
Image hash:     870bd58b5c1e (Ubuntu 22.04 LTS)
CPU(s):         1
Load:           0.08 0.10 0.07
Disk usage:     7.6GiB out of 30.9GiB
Memory usage:   148.2MiB out of 951.9MiB
Mounts:         --

That’s all !

本文地址
https://architect.pub
SEO Title
Expand a Multipass VM disk (no space left on device)

混沌工程

混沌工程 intelligentx

【DevOps】什么是混沌工程?

Chinese, Simplified

测试您可以预测的事故是必不可少的。但是随着数字化转型和云原生架构带来的复杂性,团队需要一种方法来确保应用程序能够承受生产的“混乱”。混沌工程满足了这一需求,因此组织可以提供在任何条件下都可以正常运行的强大、有弹性的云原生应用程序。

什么是混沌工程?


混沌工程是一种测试分布式软件的方法,它故意引入故障和错误场景,以验证其在面对随机中断时的弹性。这些中断可能导致应用程序以不可预测的方式做出响应,并可能在压力下崩溃。混沌工程师问为什么。

从业者将软件置于受控的模拟危机中,以测试不稳定的行为。危机可能是技术、自然或恶意事件,例如影响数据中心可用性的地震或感染应用程序和网站的网络攻击。随着软件性能下降或失败,混沌工程师的发现使开发人员能够在代码中添加弹性,因此应用程序在紧急情况下保持完好。

随着混沌工程师对他们的测试越来越有信心,他们改变了更多的变量并扩大了灾难的范围。许多灾难场景和结果使混沌工程师能够更好地模拟应用程序和微服务发生的情况,这使他们能够与开发人员共享越来越多的智能,以完善软件和云原生基础设施。

混沌工程的历史


Netflix 出于需要开创了混沌工程。 2009 年,在线视频供应商迁移到 AWS 云基础设施,为越来越多的观众提供娱乐。但是云带来了新的复杂性,例如不断增加的连接和依赖关系。与娱乐公司在其数据中心看到的负载平衡问题相比,它产生了更多的不确定性。如果云中的任何接触点出现故障,观众体验的质量可能会下降。因此,该组织寻求降低复杂性并提高生产质量。

2010 年,Netflix 推出了一项技术,可以随机关闭生产软件实例——比如在服务器机房里放一只猴子——以测试云如何处理其服务。于是,工具混沌猴诞生了。

混沌工程在 Netflix 等组织中变得成熟,并催生了 Gremlin (2016) 等技术,变得更有针对性和知识化。这门科学催生了专业的混沌工程师,他们致力于破坏云软件和与之交互的本地系统,以使其具有弹性。现在,混沌工程是一个成熟的职业,它会挑起托管的麻烦来稳定云软​​件。

混沌工程是如何工作的?


混沌工程从了解软件的预期行为开始。

Chaos engineering

  • 假设。工程师问自己,如果他们改变一个变量会发生什么。如果他们随机终止服务,他们假设服务将继续不间断。问题和假设形成假设(The question and the assumption form a hypothesis)。
  • 测试。为了检验这个假设,混沌工程师将模拟的不确定性与负载测试相结合,并观察交付应用程序的服务、基础设施、网络和设备的动荡迹象。堆栈中的任何故障都会破坏假设。
  • 爆炸半径。通过隔离和研究故障,工程师可以了解在不稳定的云条件下会发生什么。测试造成的任何损坏或影响都称为“爆炸半径”。混沌工程师可以通过控制测试来管理爆炸半径。
  • 见解。这些发现形成了对软件开发和交付过程的输入,因此新软件和微服务将更好地应对不可预见的事件。

为了减轻对生产环境的破坏,混沌工程师从非生产环境开始然后以可控的方式慢慢扩展到生产环境。一旦建立,混沌工程就成为微调服务水平指标和目标、改进警报和构建更高效仪表板的有效方法,因此您知道您正在收集准确观察和分析环境所需的所有数据。

谁使用混沌工程?


混沌工程通常起源于 DevOps 中的小团队,通常涉及在预生产和生产环境中运行的应用程序。因为它可以触及许多系统,混沌工程可以产生广泛的影响,影响整个组织的群体和利益相关者。

跨越硬件、网络和云基础设施的中断可能需要网络和基础设施架构师、风险专家、安全团队甚至采购官员的投入和参与。这是好事。测试的范围越大,混沌工程就越有用。

尽管一个小团队通常拥有和管理混沌工程工作,但这是一种通常需要来自村庄的投入并为村庄提供利益的做法。

混沌测试的好处


您可以通过测试应用程序的限制获得的洞察力为您的开发团队和您的整体业务带来很多好处。这只是健康、管理良好的混沌工程实践的一些好处。

  • 提高弹性和可靠性。混沌测试丰富了组织关于软件在压力下如何执行以及如何使其更具弹性的情报。
  • 加速创新。来自混沌测试的情报返回给开发人员,他们可以实施设计更改,使软件更耐用并提高生产质量。
  • 推进协作。开发人员并不是唯一看到优势的群体。混沌工程师从他们的实验中收集到的见解提升了技术团队的专业知识,从而缩短了响应时间和更好的协作。
  • 加快事件响应速度。通过了解可能出现的故障情况,这些团队可以加快故障排除、维修和事件响应速度。
  • 提高客户满意度。更高的弹性和更快的响应时间意味着更少的停机时间。来自开发和 SRE 团队的更大创新和协作意味着更好的软件能够以高效和高性能快速满足新客户的需求。
  • 提升业务成果。混沌测试还可以通过更快的价值实现时间、节省时间、金钱和资源以及产生更好的底线来扩展组织的竞争优势。

组织的软件越有弹性,消费者和企业客户就越能享受其服务而不会分心或失望。

混沌工程的挑战和陷阱


尽管混沌测试的好处是显而易见的,但它是一种应该慎重进行的实践。以下是最关心的问题和挑战。

  • 不必要的损坏。混沌测试的主要问题是可能造成不必要的损坏。混沌工程可能导致超出合理测试允许的实际损失。为了限制发现应用程序漏洞的成本,组织应避免超出指定爆炸范围的测试。目标是控制爆炸半径,以便您可以查明故障原因,而无需引入新的故障点。
  • 缺乏可观察性。建立这种控制说起来容易做起来难。缺乏对爆炸半径可能影响的所有系统的端到端可观察性和监控是一个常见问题。如果没有全面的可观察性,可能很难理解关键依赖关系与非关键依赖关系,或者很难有足够的上下文来理解故障或降级的真正业务影响,以便确定修复的优先级。缺乏可见性还可能使团队难以确定问题的确切根本原因,这会使补救计划复杂化。
  • 不清楚启动系统状态。另一个问题是在测试运行之前清楚地了解系统的启动状态。如果没有这种清晰度,团队可能难以理解测试的真实效果。这会降低混沌测试的有效性,并使下游系统面临更大的风险,并使控制爆炸半径变得更加困难。

如何开始混沌工程


与任何科学实验一样,开始使用混沌工程需要一些准备、组织以及监控和测量结果的能力。

  • 了解您的环境的起始状态。要计划一个控制良好的混沌测试,您应该了解您的环境的应用程序、微服务和架构设计,以便您能够识别测试的效果。拥有一个可以与最终状态进行比较的基线可以创建一个蓝图,用于在测试期间进行监控并在之后分析结果。
  • 询问可能出现的问题并建立假设。清楚了解系统的启动状态后,询问可能出现的问题。清楚了解系统的启动状态后,询问可能出现的问题。了解服务水平指标和服务水平目标,并将它们用作建立系统应如何在压力下工作的假设的基础。
  • 一次引入一个变量。为了控制爆炸半径,一次只引入一点混乱,这样你就可以欣赏结果。准备好在特定条件下中止实验,以免对生产软件造成伤害,并且如果出现问题,也要有回滚计划。在测试期间,尝试反驳假设以发现需要关注的领域以提高系统弹性。
  • 监测并记录结果。监控实验以记录应用程序行为中的任何细微差别。分析结果以查看应用程序如何响应以及测试是否达到了团队的期望。使用调查工具来了解减速和故障的确切根本原因。

控制混乱

像 Gremlin 这样的解决方案提供了关键的管理工具来计划和执行混沌工程实验。它使实验具有可重复性和可扩展性,因此团队可以将它们应用于相同或更大堆栈的未来实验。

Dynatrace 的自动和智能可观察性提供了对混沌测试效果的洞察,因此工程师可以谨慎地进行混沌实验。为了监控爆炸半径,Dynatrace 观察了正在进行混沌实验的系统。通过对整个软件堆栈的可见性,Dynatrace 提供了关键的上下文分析,以隔离混沌测试暴露的故障的根本原因。

Dynatrace 的有效监控为进行混沌测试的工程师提供了必不可少的全景镜头,帮助他们了解依赖关系并预测中断将如何影响整个系统。如果混乱超出预期,Dynatrace 的洞察力可帮助团队快速修复对应用程序功能的任何实际损害。

组织可以在数字化转型的任何阶段实现应用程序弹性,而混沌工程是一个很好的工具。然而,在玩火之前,至关重要的是要采取正确的措施来预测和应对这种方法可能带来的大量故障情况。

本文:https://jiagoushi.pro/what-chaos-engineering

SEO Title
What is chaos engineering?

【混沌工程】2021 混沌工程状态

Chinese, Simplified

在过去的十二年里,我有机会参与并见证了混沌工程的发展。出身卑微,最常遇到的问题是“你为什么要这样做?”到今天的位置,帮助确保世界顶级公司的可靠性,这是一段相当长的旅程。

我第一次开始实践这门学科,早在它有名字之前几年,在亚马逊,我们的工作就是防止零售网站宕机。当我们取得成功时,Netflix 写了他们关于 Chaos Monkey 的规范博客文章(十年前​​的今年 7 月)。这个想法成为主流,许多工程师都被迷住了。在亚马逊完成任务后,我急忙加入 Netflix,深入研究这个领域。我们能够进一步推动艺术发展,构建跨越整个 Netflix 生态系统的以开发人员为中心的解决方案,最终带来另外 9 个可用性和世界知名的客户体验。

五年前,我的联合创始人 Matthew Fornaciari 和我创立了 Gremlin,其使命很简单:建立更可靠的互联网。我们都欣喜若狂地看到这次实践已经走了多远。社区中的许多人都渴望获得更多关于如何最好地利用这种方法的数据,因此我们很自豪地展示了第一份混沌工程状态报告。

全球的工程团队使用 Chaos Engineering 故意将危害注入他们的系统、监控影响并修复故障,以免对客户体验产生负面影响。这样做,他们避免了代价高昂的停机,同时减少了 MTTD 和 MTTR,让他们的团队为未知做好准备,并保护客户体验。事实上,Gartner 预计,到 2023 年,将混沌工程实践作为 SRE 计划一部分的 80% 的组织将其平均解决时间 (MTTR) 减少 90%。我们从首份混沌工程状态报告中看到了同样的相似之处:表现最好的混沌工程团队拥有四个 9 的可用性,MTTR 不到一小时。

科尔顿安德鲁斯
格雷姆林首席执行官

主要发现

  • 增加可用性和减少 MTTR 是混沌工程最常见的两个好处
  • 经常进行混沌工程实验的团队有 >99.9% 的可用性
  • 23% 的团队的平均解决时间 (MTTR) 不到 1 小时,60% 的团队不到 12 小时
  • 网络攻击是最常运行的实验,与报告的主要故障一致
  • 虽然仍然是一种新兴实践,但大多数受访者 (60%) 至少运行过一次混沌工程攻击
  • 34% 的受访者在生产环境中进行混沌工程实验

Things break

调查显示,前 20% 的受访者拥有超过四个 9 的服务,这是一个令人印象深刻的水平。 23% 的团队的平均解决时间 (MTTR) 不到 1 小时,60% 的团队平均解决时间 (MTTR) 不到 12 小时。

您的服务的平均可用性是多少?

  可靠性 占比
  <=99% 42.5%
  99.5%-99.9% 38.1%
  >=99.99% 19.4%

 

每月平均高严重性事件数 (Sev 0 和 1)

     
  1-10 81.4%
  10-20 18.6%

 

您的平均解决时间 (MTTR) 是多少?

MTTR 占比
<1 hour 23.1%
1 hour - 12 hours 39.8%
12 hours - 1 day 15.5%
1 day - 1 week 15.2%
> 1 week 0.5%
I don't know 5.9%

 

我们所做的其中一项更有益的事情是每天进行红色与蓝色攻击。 我们让平台团队介入,对我们和我们的服务进行攻击,并将其视为真实的生产事件,通过响应并查看我们所有的运行手册并确保我们被覆盖。

 

当事情确实发生时,最常见的原因是错误的代码推送和依赖问题。 这些不是相互排斥的。 来自一个团队的错误代码推送可能会导致另一个团队的服务中断。 在团队拥有独立服务的现代系统中,测试所有服务的故障恢复能力非常重要。 运行基于网络的混沌实验,例如延迟和黑洞,确保系统解耦并且可以独立失败,从而最大限度地减少服务中断的影响。

您的事件 (SEV0 和 1) 的百分比是由以下原因引起的:

  <20% 21-40% 41-60% 61-80% >80%
错误的代码部署(例如,部署到生产环境的代码中的错误导致事件) 39% 24% 19% 11.8% 6.1%
内部依赖问题(非 DB)(例如,贵公司运营的服务中断) 41% 25% 20% 10.1% 3.7%
配置错误(例如,云基础设施或容器编排器中的错误设置导致事件) 48% 23% 14% 10.1% 5.2%
网络问题(例如,ISP 或 DNS 中断) 50% 19% 13% 15.7% 1.7%
第 3 方依赖问题(非 DB)(例如,与支付处理器的连接断开) 48% 23% 13% 14.3% 1.7%
托管服务提供商问题(例如,云提供商 AZ 中断) 61% 14% 9% 12.5% 3.9%
机器/基础设施故障(本地)(例如,停电) 64% 14% 6% 12% 4.4%
数据库、消息传递或缓存问题(例如,导致事件的数据库节点丢失) 58% 18% 18% 5.2% 1.2%
未知 66% 10% 15% 7.4% 1%

 

谁知道

可用性监控因公司而异。例如,Netflix 的流量非常稳定,他们可以使用服务器端每秒的视频启动次数来发现中断。与预测模式的任何偏差都表示中断。 Google 将真实用户监控与窗口结合使用来确定单个中断是否会产生重大影响,或者多个小事件是否会影响服务,从而对事件的原因进行更深入的分析。很少有公司像 Netflix 和 Google 那样拥有一致的流量模式和复杂的统计模型。这就是为什么使用综合监控的标准正常运行时间作为监控服务正常运行时间的最流行方法位于顶部,而许多组织使用多种方法和指标。我们惊喜地发现所有受访者都在监控可用性。这通常是团队为积极改善应用程序中的客户体验而采取的第一步。

您使用什么指标来定义可用性?

可用性指标 占比
错误率(失败请求/总请求) 47.9%
延迟 38.3%
订单/交易与历史预测 21.6%
成功请求/总请求 44%
正常运行时间/总时间段 53.3%

 

您如何监控可用性?

监控方式 占比
真实用户监控 37.1%
健康检查/合成 64.4%
服务器端响应 50.4%

 

在查看谁收到有关可用性和性能的报告时,人们越接近操作应用程序,他们收到报告的可能性就越大也就不足为奇了。 我们相信,随着构建和运营的思维方式在组织中变得普遍,DevOps 将运维和开发紧密结合在一起的趋势是使开发人员与运维保持一致。 我们还相信,随着数字化程度的提高和在线用户体验变得更加重要,我们将看到接收可用性和绩效报告的 C 级员工的百分比增加。

谁监控或接收可用性报告?

   
CEO 15.7%
CFO or VP of Finance 11.8%
CTO 33.7%
VP 30.2%
Managers 51.1%
Ops 61.4%
Developers 54.5%
Other 1.2%

谁监控或接收性能报告?

   
CEO 12%
CFO or VP of Finance 10.6%
CTO 36.1%
VP 28.3%
Managers 51.8%
Ops 53.8%
Developers 54.1%
Other 2%

最好表现者

表现最好的人有 99.99% 以上的可用性和不到一小时的 MTTR(上面突出显示)。 为了获得这些令人印象深刻的数字,我们调查了团队使用的工具。 值得注意的是,自动缩放、负载平衡器、备份、部署的选择推出以及通过运行状况检查进行监控在顶级可用性组中更为常见。 其中一些,例如多区域,是昂贵的,而其他的,例如断路器和选择推出,是时间和工程专业知识的问题。

始终进行混沌实验的团队比从未进行过实验或临时进行实验的团队具有更高的可用性水平。 但 ad-hoc 实验是实践的重要组成部分,可用性 > 99.9% 的团队正在执行更多的 ad-hoc 实验。

混沌工程实验的频率(按可用性)

  Never performed an attack Performed ad-hoc attacks Quarterly attacks Monthly attacks Weekly attacks Daily or more frequent attacks
>99.9% 25.7% 28.4% 16.2% 6.8% 17.6% 5.4%
99%-99.9%% 35.7% 25% 11.6% 10.3% 8.5% 8.9%
<99%% 49.4% 18.1% 13.3% 8.4% 8.4% 2.4%

 

按可用性使用工具

  >99.9% 99%-99.9% <99%

Autoscaling

65% 52% 43%
DNS failover/elastic IPs 49% 33% 24%
Load balancers 77% 64% 71%
Active-active multi-region, AZ or DC 38% 29% 19%
Active-passive multi-region, AZ, or DC 45% 34% 30%
Circuit breakers 32% 22% 16%
Backups 61% 46% 51%
DB replication 51% 47% 37%
Retry logic 41% 33% 31%
Select rollouts of deployments (Blue/Green, Canary, feature flags) 51% 36% 27%
Cached static pages when dynamic unavailable 26% 26% 19%
Monitoring with health checks 70% 58% 53%

混沌工程的演变

2010 年,Netflix 将 Chaos Monkey 引入他们的系统。 这种节点的伪随机故障是对实例和服务器随机故障的响应。 Netflix 希望团队为这些故障模式做好准备,因此他们加快了流程,要求对实例中断具有弹性。 它创建了对可靠性机制的测试,并迫使开发人员在构建时考虑到失败。 基于该项目的成功,Netflix 开源了 Chaos Monkey,并创建了 Chaos Engineer 角色。 从那时起,混沌工程已经发展到遵循科学过程,并且实验已经扩展到主机故障之外,以测试堆栈上下的故障。

谷歌搜索“混沌工程”

年份 搜索次数
2016 1290
2017 6990
2018 19100
2019 24800
2020 31317

 

对于失败中花费的每一美元,学习一美元的教训

-----“MASTER OF DISASTER”

------JESSE ROBBINS

2020 年,混沌工程成为主流,并成为 Politico 和彭博社的头条新闻。 Gremlin 举办了有史以来规模最大的混沌工程活动,有超过 3,500 名注册者。 Github 拥有超过 200 个混沌工程相关项目,拥有 16K+ 星。 最近,AWS 宣布他们自己的公开混沌工程产品 AWS 故障注入模拟器将于今年晚些时候推出。

Chaos Engineering today

混沌工程正变得越来越流行和改进:60% 的受访者表示他们已经运行过混沌工程攻击。 Chaos Engineering 的创建者 Netflix 和 Amazon 是尖端的大型组织,但我们也看到更成熟的组织和较小的团队采用。 使用混沌工程的团队的多样性也在增长。 最初的工程实践很快被站点可靠性工程 (SRE) 团队采用,现在许多平台、基础设施、运营和应用程序开发团队正在采用这种实践来提高其应用程序的可靠性。 主机故障,我们归类为状态类型攻击,远不如网络和资源攻击流行。 我们已经看到了模拟与依赖项的丢失连接或对服务的需求激增的情况。 我们还看到更多的组织将他们的实验转移到生产中,尽管这还处于早期阶段。

 

使用 Gremlin 平台的 459,548 次攻击

68% 的客户使用 K8S 攻击

您的组织多久练习一次混沌工程?

  每日或更频繁的攻击 每周攻击 每月攻击 每季度攻击 执行临时攻击 从未进行过攻击
>10,000员工 5.7% 8% 4.6% 16.1% 31% 34.5%
5,001-10,000 员工 0% 13.2% 18.4% 21.1% 23.7% 23.7%
1,001-5,000 员工 8.3% 11.1% 8.3% 9.7% 22.2% 40.3%
100-1,000 员工 10.9% 10.9% 8.6% 10.9% 22.7% 35.9%
<100 员工 3.7% 7.3% 9.8% 8.5% 15.9% 54.9%

 

哪些团队参与了混沌实验?

   
Application Developers 52%
C-level 10%
Infrastructure 42%
Managers 32%
Operations 49%
Platform or Architecture 37%
SRE 50%
VPs 14%

 

您的组织中有多少百分比使用混沌工程?

  百分比
76%+ 7.3%
51-75% 17.7%
26-50% 21%
<25% 54%

你在什么环境下进行过混沌实验?

   
Dev/Test 63%
Staging 50%
Production 34%

 

按类型划分的攻击百分比

   
Network 46%
Resource 38%
State 15%
Application 1%

按目标类型划分的攻击百分比

   
Host 70%
Container 29%
Application 1%

混沌实验结果

混沌工程最令人兴奋和最有价值的方面之一是发现或验证错误。 这种做法可以更容易地在未知问题影响客户之前发现它们并确定事件的真正原因,从而加快修补过程。 对我们调查的回复中显示的另一个主要好处是更好地理解架构。 运行混沌实验有助于识别对我们的应用程序产生不利影响的紧密耦合或未知依赖关系,并且通常会消除创建微服务应用程序的许多好处。 从我们自己的产品中,我们发现客户经常发现事件、缓解问题并使用 Chaos Engineering 验证修复。 我们的调查受访者经常发现他们的应用程序在减少 MTTR 的同时提高了可用性。

使用混沌工程后,你体验到了什么好处?

   
提高可用性 47%

缩短平均解决时间 (MTTR)

mean time to resolution

45%

缩短平均检测时间 (MTTD)

mean time to detection

41%
减少了交付到生产环境的错误数量 38%
减少中断次数 37%
减少页面数 25%

 

混沌工程的未来

采用/扩展混沌工程的最大障碍是什么?

   
缺乏认识 20%
其他优先事项 20%
缺乏经验 20%
时间不够 17%
安全问题 12%
害怕出事 11%

采用混沌工程的最大障碍是缺乏意识和经验。紧随其后的是“其他优先事项”,但有趣的是,超过 10% 的人提到担心可能出现问题也是一个禁忌。确实,在实践混沌工程时,我们正在将故障注入系统,但使用遵循科学原理的现代方法,并有条不紊地将实验隔离到单一服务中,我们可以有意识地实践而不破坏客户体验。

我们相信混沌工程的下一阶段涉及向更广泛的受众开放这一重要的测试过程,并使其更容易在更多环境中安全地进行实验。随着实践的成熟和工具的发展,我们希望工程师和操作员能够更容易和更快地设计和运行实验,以提高其系统跨环境的可靠性——今天,30% 的受访者正在生产中运行混沌实验。我们相信,混沌实验将变得更有针对性和自动化,同时也变得更加普遍和频繁。

我们对混沌工程的未来及其在使系统更可靠方面的作用感到兴奋。

人口统计

本报告的数据源包括一项包含 400 多个回复的综合调查和 Gremlin 的产品数据。 调查受访者来自各种规模和行业,主要是软件和服务。 混沌工程的采用已经冲击了企业,近 50% 的受访者为员工人数超过 1,000 人的公司工作,近 20% 的受访者为员工人数超过 10,000 人的公司工作。

该调查强调了云计算的一个转折点,近 60% 的受访者在云中运行大部分工作负载,并使用 CI/CD 管道。 容器和 Kubernetes 正在达到类似的成熟度,但调查证实服务网格仍处于早期阶段。 最常见的云平台是 AWS,占比接近 40%,GCP、Azure 和本地云平台紧随其后,占比约为 11-12%。

400 多名合格的受访者

贵公司有多少员工?

   
>10,000 21.4%
5,001-10,000 9.3%
1,001-5,000 17.7%
100-1,000 31.4%
<100 20.1%

你的公司几岁了?

   
Over 25 years old 25.8%
10 to 25 years old 32.9%
2 to 10 years old 27.3%
Less than 2 years old 14%

贵公司属于哪个行业?

   
Software & Services 50.2%
Banks, Insurance & Financial Services 23.2%
Energy Equipment & Services 0.7%
Retail & eCommerce 18.3%
Technology Hardware, Semiconductors, & Related Equipment 7.6%

你的职位是什么?

   
Software Engineer 32.2%
SRE 25.3%
Engineering Manager 18.2%
System Administrator 8.8%
Non-technical Executive (ex: CEO, COO, CMO, CRO) 4.9%
Technical Executive (ex: CTO, CISO, CIO) 10.6%

 

云中占生产工作负载的百分比是多少?

   
>75% 35.1%
51-75% 23.1%
25-50% 21.4%
<25% 20.4%

 

使用 CI/CD 管道部署的生产工作负载的百分比是多少?

   
>75% 39.8%
51-75% 21.1%
25-50% 20.4%
<25% 18.7%

百分之几的生产工作负载使用容器?

   
>75% 27.5%
51-75% 19.9%
25-50% 23.6%
<25% 29%

百分之几的生产工作负载使用 Kubernetes(或其他容器编排器)?

 

   
>75% 19.4%
51-75% 22.4%
25-50% 18.4%
<25% 39.8%

百分之多少的生产环境路由利用了服务网格?

   
>75% 0.1%
51-75% 116.5%
25-50% 17.9%
<25% 55.5%

 

除了检查调查结果外,我们还汇总了有关 Gremlin 用户技术环境的信息,以了解哪些特定工具和堆栈层最常成为混沌工程实验的目标。 这些发现如下。

您的云提供商是什么?

   
Amazon Web Services 38%
Google Cloud Platform 12%
Microsoft Azure 12%
Oracle 2%
Private Cloud (On Premises) 11%

你的容器编排器是什么?

   
Amazon Elastic Container Service 13%
Amazon Elastic Kubernetes Service 19%
Custom Kubernetes 16%
Google Kubernetes Engine 12%
OpenShift 6%

您的消息传递提供者( messaging provider)是什么?

   
ActiveMQ 5%
AWS SQS 17%
Kafka 25%
IBM MQ 1%
RabbitMQ 13%

 

你的监控工具是什么?

   
Amazon CloudWatch 28%
Datadog 13%
Grafana 18%
New Relic 9%
Prometheus 18%

 

你的数据库是什么?

   
Cassandra 5%
DynamoDb 14%
MongoDB 16%
MySQL 22%
Postgres 22%

 

贡献者

Dynatrace

Dynatrace 提供软件智能以简化云复杂性并加速数字化转型。 借助自动和智能的大规模可观察性,我们的一体化平台可提供有关应用程序性能和安全性、底层基础架构以及所有用户体验的准确答案,使组织能够更快地创新、更有效地协作并交付更多 以更少的努力获得价值。

Epsagon

Epsagon 使团队能够立即可视化、理解和优化他们的微服务架构。 借助我们独特的轻量级自动仪表,消除了与其他 APM 解决方案相关的数据和手动工作方面的空白,从而显着减少了问题检测、根本原因分析和解决时间。

Grafana Labs


Grafana Labs 提供了一个围绕 Grafana 构建的开放且可组合的监控和可观察性平台,Grafana 是用于仪表板和可视化的领先开源技术。 超过 1,000 家客户(如 Bloomberg、JP Morgan Chase、eBay、PayPal 和 Sony)使用 Grafana Labs,全球有超过 600,000 个 Grafana 活跃安装。 商业产品包括 Grafana Cloud,一个集成了 Prometheus 和 Graphite(指标)的托管堆栈,Grafana Enterprise,一个具有企业功能、插件和支持的 Grafana 增强版; Loki(原木)和 Tempo(痕迹)与 Grafana; 和 Grafana Metrics Enterprise,它为大规模运行的大型组织提供 Prometheus 即服务。

LaunchDarkly

LaunchDarkly 由 Edith Harbaugh 和 John Kodumal 于 2014 年创立,是软件团队用来构建更好的软件、更快、风险更低的功能管理平台。 开发团队使用功能管理作为将代码部署与功能发布分开的最佳实践。 使用 LaunchDarkly,团队可以控制从概念到发布再到价值的整个功能生命周期。 每天为超过 1 万亿个功能标志提供服务,LaunchDarkly 被 Atlassian、Microsoft 和 CircleCI 的团队使用。

 

PagerDuty

PagerDuty, Inc. (NYSE:PD) 是数字运营管理领域的领导者。 在一个永远在线的世界中,各种规模的组织都信任 PagerDuty 可以帮助他们每次都为客户提供完美的数字体验。 团队使用 PagerDuty 实时识别问题和机会,并召集合适的人员更快地解决问题并在未来预防问题。 知名客户包括 GE、思科、基因泰克、艺电、Cox Automotive、Netflix、Shopify、Zoom、DoorDash、Lululemon 等。

本文:https://jiagoushi.pro/2021-state-chaos-engineering

SEO Title
2021 STATE OF CHAOS ENGINEERING

【混沌工程】Wikipedia Chaos engineering

Chinese, Simplified

混沌工程是在系统上进行实验的学科,目的是建立对系统在生产中承受动荡条件的能力的信心。 

概念


在软件开发中,一个给定的软件系统在保证足够服务质量的同时容忍故障的能力——通常被概括为弹性——通常被指定为一项要求。但是,由于截止日期短或缺乏该领域的知识等因素,开发团队经常无法满足这一要求。混沌工程是一种满足弹性要求的技术。

混沌工程可用于实现针对基础设施故障、网络故障和应用程序故障的弹性

历史


在 2011 年监督 Netflix 向云迁移的过程中,[2][3] Greg Orzell 的想法是通过设置一个工具来解决缺乏足够的弹性测试的问题,该工具会导致其生产环境(Netflix 客户使用的环境)出现故障。其目的是从假设没有故障的开发模型转变为故障被认为是不可避免的模型,从而促使开发人员将内置弹性视为一种义务而不是一种选择:

“在 Netflix,我们的自由和责任文化使我们不强迫工程师以特定方式设计他们的代码。相反,我们发现我们可以通过隔离服务器中和和将它们推向极致。我们创建了 Chaos Monkey,这是一个随机选择服务器并在正常活动时间内禁用它的程序。有些人会觉得这很疯狂,但我们不能依赖随机发生的事件来测试我们的面对这一事件的后果时采取的行为。知道这种情况会经常发生,因此工程师之间建立了强烈的一致性,以建立冗余和流程自动化以在此类事件中幸存下来,而不影响数百万 Netflix 用户。Chaos Monkey 是我们的一员提高我们服务质量的最有效工具。”[4]

通过定期“杀死”软件服务的随机实例,可以测试冗余架构以验证服务器故障不会明显影响客户。

混沌工程的概念与 Martin Fowler 于 2012 年首次提出的 Phoenix Servers 很接近。 [5]

扰动(Perturbation)模型


混沌工程工具实现了扰动模型。扰动,也称为湍流,旨在模拟生产中可能发生的罕见或灾难性事件。为了最大化混沌工程的附加值,预计扰动是现实的。 [6]

服务器关闭


一种扰动模型包括随机关闭服务器。 Netflix 的 Chaos Monkey 就是这种扰动模型的实现。


延迟注入


引入通信延迟以模拟网络中的退化或中断。例如,Chaos Mesh 支持延迟注入。


资源枯竭


吃掉给定的资源。例如,Gremlin 可以填满磁盘。


混沌工程工具

Chaos Monkey

Chaos Monkey 是 Netflix 于 2011 年发明的一种工具,用于测试其 IT 基础架构的弹性。 [2]它通过故意禁用 Netflix 生产网络中的计算机来测试剩余系统如何响应中断来工作。 Chaos Monkey 现在是名为 Simian Army 的更大工具套件的一部分,旨在模拟和测试对各种系统故障和边缘情况的响应。

Chaos Monkey 背后的代码由 Netflix 于 2012 年在 Apache 2.0 许可下发布。

“混沌猴”这个名字在安东尼奥·加西亚·马丁内斯的《混沌猴》一书中有解释:

  • 想象一只猴子进入“数据中心”,这些服务器“农场”承载着我们在线活动的所有关键功能。猴子随机撕开电缆,破坏设备并归还所有经过手的东西[即扔粪便]。 IT 经理面临的挑战是设计他们负责的信息系统,以便它能够在这些猴子的情况下工作,没有人知道它们何时到达以及它们将破坏什么。

Simian Army


Simian Army 是 Netflix 开发的一套工具,用于测试其亚马逊网络服务基础设施的可靠性、安全性或弹性,包括以下工具:

在Simian Army 等级的最顶端,Chaos Kong 放弃了一个完整的 AWS“区域”。 虽然很少见,但确实会发生整个区域的损失,Chaos Kong 模拟了系统对此类事件的响应和恢复。

Chaos Gorilla 放弃了一个完整的亚马逊“可用区”(一个或多个服务于一个地理区域的完整数据中心)。

ChaosMachine


ChaosMachine 是一个在 JVM 的应用程序级别进行混沌工程的工具。它专注于通过注入异常来分析应用程序中涉及的每个 try-catch 块的错误处理能力。

Proofdock混沌工程平台


Proofdock 是一个混沌工程平台,专注于并利用 Microsoft Azure 平台和 Azure DevOps 服务。用户可以在基础设施、平台和应用程序级别注入故障。 

Gremlin


Gremlin 是一个“故障即服务”平台。 

Facebook Storm


为了应对数据中心的损失,Facebook 定期测试其基础设施对极端事件的抵抗力。该程序被称为 Storm Project,它模拟大规模数据中心故障。 

Days of Chaos


Voyages-sncf.com 于 2017 年创建了“混沌之日”,将预生产故障的模拟游戏化。他们在 2017 DevOps REX 会议上展示了他们的结果。 

See also

本文:

SEO Title
Wikipedia Chaos engineering

【混沌工程】什么是混沌工程?

Chinese, Simplified

什么是混沌工程?

混沌工程让您可以将您认为会发生的事情与系统中实际发生的事情进行比较。 您实际上是“故意破坏”以学习如何构建更具弹性的系统。

通过主动测试系统在压力下的响应方式,我们可以在故障出现之前识别并修复故障。 最终,混沌工程的目标是增强我们系统的稳定性和弹性。

混沌与可靠性工程技术作为构建可靠应用程序的基本学科正迅速获得关注。 在过去的几年里,许多组织——无论大小——都接受了混沌工程。

创建可靠的软件是现代云应用程序和架构的基本必要条件。 随着我们迁移到云或将我们的系统重新架构为云原生,我们的系统正在按设计分布,并且出现计划外故障和意外中断的可能性显着增加。 此外,转向 DevOps 会使可靠性测试更加复杂。

DevOps 抛弃了传统的可靠性测试

像 QA 和其他测试学科的出现是为了应对不断出现的问题并需要一种新的测试方法。

例如,单元测试验证我们编写的一些代码是否符合预期。集成测试验证我们编写的代码可以很好地与代码库的其余部分配合使用。有时我们会进行系统测试,试图验证整个系统是否符合设计规范。传统上,开发团队会传递他们的代码进行测试,以验证它是否按预期工作或发现需要修复的问题。

在这一点上,代码将被扔到一个运营团队的墙外,他们的工作是让代码在生产环境中运行。运维负责让东西运行起来,并且由于每个组织环境的独特性,各个运维团队都会提出自己的战略和计划。

DevOps 将开发和运营团队合并在一起,让他们共同承担生产准备和部署的责任。敏捷和 DevOps 软件流程将我们的开发和部署速度提高了几个数量级,因此我们可以更快地将产品和功能提供给客户。

但是,越快的代码被创建并检入到 master 中,QA 就越频繁地编写测试并且需要更多的测试。速度越快,偶尔出现错误的可能性就会越大。为了跟上步伐,测试已尽可能自动化。

此外,随着我​​们转向微服务和其他分布式、基于云的架构。这些分布式系统具有紧急行为,通过扩大和缩小规模来响应各种生产条件,以确保应用程序能够为不断增长的客户需求提供无缝体验。换句话说,这些系统从不遵循相同的路径来获得客户体验。紧急行为也意味着紧急失败。分布式系统会失败,但它们不太可能以同样的方式失败两次。

我们之前对测试的理解并不能解释当今独特且不断变化的生产环境。 DevOps 的 Ops 方面尽最大努力使事情顺利进行,但他们的任务通常只涉及将代码投入生产并希望获得最佳效果或回滚更改或在发生故障时进行修补程序。他们自动化了一些测试,但通常不会运行会发现由生产中的动荡条件引起的系统故障的测试。

传统的 QA 已经不够用了

DevOps 中缺少一些东西:混沌工程是您一直在寻找的测试方法。

传统的质量保证仅涵盖我们软件堆栈的应用层。 再多的传统 QA 测试或其他传统测试都无法验证我们的应用程序、其各种服务或整个系统是否会在任何条件下可靠地响应,无论是“按设计工作”还是在极端负载和异常情况下。

任何软件堆栈或应用程序层的故障都可能破坏客户体验。 传统的 QA 测试方法不会在这些潜在问题条件实际发生之前发现它们。

此外,大多数传统的 QA 活动都被其他团队吸收了。 许多测试现在由 CI/CD 管道自动化,并由 SRE 或 DevOps 团队监督。 发现和解决问题的责任已成为服务所有者的责任。 除此之外,不可否认的事实是,不可能建立准确模仿生产环境的测试和登台环境。

混沌工程如何帮助测试发展?

  • 验证
    • 更广泛的软件和基础设施场景
  • 发现问题
    • 传统测试无法暴露
  • 安全地进行
    • 并在生产中有效
  • 帮助团队了解
    • 系统在现实世界中的行为方式,而不仅仅是它们如何破坏或它们有什么错误

由于混沌工程可以在运行时测试代码质量,并且具有自动化和手动测试形式的潜力,因此该学科成为新质量评估工具箱中的强大工具。

早些时候我们解释了分布式系统是如何不断变化的,这意味着它们永远不会以相同的方式崩溃两次,但它们会崩溃。 Chaos Engineering 允许工程师在安全和受控的环境中模拟他们的系统如何响应故障,从而帮助企业防范这些故障。

我们使用混沌实验来模拟我们知道有可能导致问题的金丝雀实例上的事物,例如网络延迟。新服务在轻量级测试下是否有效?中等的?重的?我们努力推动新实例。在生产中。我们逐渐建立起来,甚至测试超出了我们期望的工作点。我们学到了东西。我们经常学到的东西会创造机会在下一次构建中进一步完善我们的工作。这在生产中是安全的,因为服务的其他实例正在处理客户需求;甚至没有人能说我们正在做混沌工程。

混沌工程是在当今复杂的现实中发现系统性问题的唯一方法,无论我们是否使用金丝雀部署。当网络延迟增加两微秒时,我们的 REST API 驱动的库存服务将如何表现?当大量延迟的请求全部并发到微服务时会发生什么?我们怎么知道?我们对其进行测试。

混沌工程入门

我们首先设计了一个小型混沌实验,其规模远小于我们认为可能造成麻烦的规模。接下来,我们限制爆炸半径和真正的潜在危害,以便在进行混沌测试时保证系统和数据的安全。然后,我们运行实验,完成后,我们仔细检查我们的监控和可观察性以及其他系统数据,看看我们学到了什么。

我们的混沌实验影响了什么?这些数据决定了我们如何优先考虑我们的工作,在我们发现的小问题变成大问题之前减轻它们(并且肯定会减轻我们立即发现的任何大问题!)。然后我们通过再次运行相同的混沌实验来跟进我们的工作,以确认我们的工作是有效的。

反复这样做,从小处着手,每次都修复我们发现的东西,很快就会加起来。我们的系统在处理我们无法控制或阻止的现实世界事件方面变得越来越好,例如当我们的云提供商发生意外中断时。

“哦,不!我们在 us-east-2 中的 Amazon S3 存储桶刚刚坏了?”不用担心,我们已经预料到了这一点,并且从客户的角度来看,我们的系统仍然表现良好。也许我们已经在 us-west-1 中进行了故障转移备份,并设计了我们的系统,以便在性能下降到一定水平时进行切换,而客户会注意到。

无论我们的解决方案是什么,我们都设计了它,我们实现了它,然后我们用混沌工程对其进行了测试。结果,当发生我们无法控制的生产故障时,它按预期工作,更重要的是,我们的客户甚至都不知道它发生了。

本文:https://jiagoushi.pro/gremlin-what-chaos-engineering

SEO Title
gremlin: What is Chaos Engineering?

【混沌工程】什么是混沌工程? 介绍、定义及更多

Chinese, Simplified

软件和系统开发是创新和解决未知问题的练习。 软件和系统是容易出错的,因为它们是由具有不同观点和技能的人(很可能是多人)制作的。 技术变得越来越分散和复杂,尤其是随着微服务的推动。 很少有人拥有完整的端到端知识 […]

软件和系统开发是创新和解决未知问题的练习。软件和系统是容易出错的,因为它们是由具有不同观点和技能的人(很可能是多人)制作的。技术变得越来越分散和复杂,尤其是随着微服务的推动。很少有人拥有整个系统的全部端到端知识。

类似于围绕态势感知的军事术语,战争迷雾,在现代发展中理解变化的总体影响可能很困难(发展迷雾)。再加上用户对系统始终可用的期望,测试系统的稳健性和对未知数的弹性可能只是:一个未知数。

混沌工程通过在整个应用程序和基础架构堆栈中注入故障,然后允许工程师验证行为并进行调整,从而使故障不会向用户显现,从而帮助解决未知问题。再加上站点可靠性工程实践的兴起,混沌工程试图计算不可能的影响。

混沌史


站点可靠性工程师的热门读物是 Nicholas Taleb 的《黑天鹅:极不可能的影响》(2007 年)。塔勒布在他的作品中介绍了黑天鹅的隐喻。塔勒布将黑天鹅事件分类,例如突然的自然灾害或在出版他的书时的商业活动,谷歌取得了惊人的空前成功。黑天鹅事件具有三个特征:不可预测,影响巨大,当它结束时,我们会设计一种解释,让黑天鹅看起来不那么随机。

在处理发展的迷雾时,我们很容易陷入分布式计算的谬误,这是计算机科学家 Peter Deutsch 提出的一组关键断言。一些主要的谬误是:网络可靠,延迟为零,带宽无限,并且只有一名管理员。消除谬误,您的服务将始终如一,并且随时可用。正如我们所知,系统和服务总是会起起落落——但是当涉及到开发未知的细节时,我们很容易忘记这一点。

例如,假设我们正在构建一些依赖 Amazon S3 进行对象存储的功能。如果我们正在为执行复杂处理的服务构建功能并且最终输出是在 S3 中写入或更新对象,我们作为工程师可能会假设 S3 将在那里。我们上下测试我们的功能,并为 S3 部分提供不太复杂的测试覆盖率。亚马逊网络服务在 2017 年发生了自己的黑天鹅事件,当时 S3 遭遇中断。我们认为会存在的东西(即使性能/写入 SLA 降低)也没有,分布式计算的谬误又回来咬我们。

S3 中断确实有助于确保我们接触到堆栈的所有部分,即使我们接触的部分看起来并不明显,这可能是由于我们对分布式计算的谬误的看法/迷雾。混沌工程和混沌实验带来了可控的混沌,因此我们可以摆脱这些类型的事件。

什么是混沌工程?


混沌工程是故意将故障注入系统以衡量弹性的科学。与任何科学方法一样,混沌工程专注于实验/假设,然后将结果与对照(稳态)进行比较。分布式系统中典型的混沌工程示例是关闭随机服务,以查看项目如何响应以及对用户旅程的损害表现在哪些方面。

如果您对应用程序需要运行的内容(计算、存储、网络和应用程序基础设施)进行横截面分析,则将故障或动荡条件注入该堆栈的任何部分都是有效的混沌工程实验。网络饱和或存储突然变得不稳定/满负荷是技术行业已知的故障,但混沌工程允许对这些故障进行更可控的测试,等等。由于可能会影响广泛的基础设施,混沌工程的用户和从业者几乎可以是支持应用程序/基础设施堆栈的任何人。

谁使用混沌工程?


由于混沌工程涉及广泛的技术和决策,混沌工程实验可能有多个利益相关者。爆炸半径越大(受测试和实验影响的范围),参与的利益相关者就越多。

根据应用程序堆栈的领域(计算、网络、存储和应用程序基础架构)以及目标基础架构所在的位置,这些团队的利益相关者可以参与其中。

如果爆炸半径很小并且可以在运行的容器中进行测试,那么应用程序开发团队可以进行测试,而不必担心突破容器。如果工作负载或基础设施的影响范围更广(例如,测试 Kubernetes 基础设施),平台工程团队很可能会参与其中。为未知提供覆盖是运行 Chaos 测试和寻找弱点的核心原因。

为什么要进行混沌测试?


开发的迷雾是非常真实的,尤其是对于更大的分布式系统、复杂系统和微服务实现。从应用程序的角度来看,每个单独的微服务都可以单独测试并确定按设计工作。正常的监控技术可以认为单个服务是健康的。

使用微服务模式,单个请求可以遍历多个服务以获得聚合响应来满足用户或其他服务的请求。服务之间的每个远程请求都在遍历额外的基础设施并跨越不同的应用程序边界,所有这些都可能失败。

如果一项琐碎或非​​琐碎的服务或基础设施在服务水平协议 (SLA) 范围内没有响应,系统的功能和用户旅程将受到怎样的影响?这正是混沌工程正在解决的问题。混沌工程实验的结果随后被用于创建一个更具弹性的系统。

混沌工程原理


《混沌工程原理》是一篇出色的宣言,描述了混沌工程的主要目标和原则。混沌工程原理进一步分解了四种类似于科学方法的实践。但是,与科学方法不同的是,假设系统是稳定的,然后寻找方差。越难中断稳态,系统的信心和稳健性就越高。

从定义基线开始(稳态)


了解什么是正常/稳定对于检测偏差/回归至关重要。根据您要测试的内容,拥有一个良好的指标,例如响应时间或更高级别的目标,例如在特定时间内完成用户旅程的能力,是衡量正常性的良好指标。实验中的稳态是对照组。

假设稳态将持续


与科学方法背道而驰,假设一个假设一直都是真的不会留下太多的余地。混沌工程旨在针对强大而稳定的系统运行,试图找出应用程序故障或基础设施故障等故障。对不稳定的系统运行混沌工程并没有提供太多价值,因为这些系统已经不可靠并且不稳定性是已知的。

引入变量/实验


与任何科学实验一样,混沌工程在实验中引入变量以查看系统如何响应。这些实验代表了影响应用程序四大支柱中的一个或多个的真实故障场景:计算、网络、存储和应用程序基础设施。例如,故障可能是硬件故障或网络中断。

尝试反驳假设


如果假设是针对稳态的,则稳态的任何方差或中断(对照组和实验组之间的差异)都反驳了稳定性假设。现在有了一个可以关注的领域,可以进行修复或设计更改,以使系统更加健壮和稳定。

在实施混沌工程实验时,实施混沌工程的原则会导致一些设计注意事项和最佳实践。

混沌工程最佳实践


在实施混沌工程或任何测试时,有三个支柱。第一个是提供足够的覆盖范围,第二个是确保经常运行实验并在生产中模拟/运行,第三个是最小化爆炸半径。

为估计的故障频率/影响提供覆盖范围


在软件中,您永远不会达到 100% 的测试覆盖率。建立覆盖需要时间,而考虑每个特定场景是一个白日梦。覆盖范围致力于使最有影响力的测试。在混沌工程中,这将测试会产生严重影响的项目,例如存储不可用或可能发生很多的项目,例如网络饱和或网络故障。

在您的管道中连续运行实验


软件、系统和基础设施确实会发生变化——每个人的状况/健康状况都可能会迅速发生变化。运行实验的好地方是在 CI/CD 管道中。 CI/CD 管道在进行更改时执行。衡量变革的潜在影响的最佳时机莫过于变革开始在管道中建立信心的旅程。

在生产中运行实验


正如在生产中进行测试的可怕想法一样,生产是用户所处的环境,流量峰值/负载是真实的。为了全面测试生产系统的稳健性/弹性,在生产环境中运行混沌工程实验将提供所需的见解。

最小化爆炸半径


因为你不能以科学的名义降低生产,所以限制混沌工程实验的爆炸半径是一种负责任的做法。专注于小实验,这些实验会告诉你你想要识别什么。专注于范围和测试。例如,两个特定服务之间的网络延迟。比赛日计划可以帮助计算爆炸半径和重点。

有了这些最佳实践,混沌工程是一门不同于负载测试的学科。

混沌工程和负载测试有什么区别?


当然,负载本身会带来混乱。我们通常将我们的系统设计为在多个部分中具有弹性(启动额外的计算、网络、持久性和/或应用程序节点以应对负载)。那是假设一切都在同一/适当的时间出现,因此我们可以领先于负载。

在计算机科学领域,Thundering Herd 问题(惊群问题)并不新鲜,但随着我们向更加分布式的架构迈进,它会更加普遍地表现出来。例如,Thundering Herd 问题可能在机器级别,因为大量进程被启动,另一个进程成为瓶颈(处理一个且仅一个新进程的能力)。在分布式架构中,Thundering Herd 可能是您的消息系统能够一次摄取大量消息/事件,但处理/持久化这些消息可能会成为瓶颈。如果您收到消息过多,您好 Thundering Herd。

负载测试肯定会帮助我们为雷鸣群做准备,这是一种压力,但是如果系统的一部分甚至不存在,或者游戏迟到了怎么办?这就是混沌工程的用武之地。如果没有混沌工程,一个非常难以测试的项目将是级联故障。历史上更等同于电网,级联故障是一个部分的故障可以触发其他部分的故障。在分布式系统领域,这是我们试图找到单点故障并确保我们的应用程序/基础设施足够健壮以处理故障。

今天,不乏工具和平台来帮助您实现混沌工程目标。

混沌工程工具


围绕混沌工程有很多进步和工具。很棒的资源列表是 Awesome Chaos Engineering 列表。此列表向构建 Chaos Engineering 的混沌测试工具致敬,向使 Chaos Engineering 更易于使用的新平台致敬。

混沌猴(Chaos Monkey)


Chaos Monkey 被公认为最早的混沌工程工具之一,由 Netflix 开发。最初的 Chaos Monkey 会随机禁用生产实例。最终,混沌猴成为了猿猴军团(Simian Army)的一员。尽管今天 Chaos Monkey 是一个独立的项目。

四面军(The Simian Army)


受原始 Chaos Monkey 成功的启发,Simian Army 是一系列工具(例如 Janitor Monkey、Latency Monkey、Security Monkey 和 Doctor Monkey),专注于引入不同类型的故障。今天,四面军退役了。

Gremlin 平台(Gremlin Platform)


Gremlin 是最早的 SaaS 混沌工程平台之一。 Gremlin 能够协调和测量打包在 SaaS 平台中的混沌工程实验。如果这是您第一次涉足混沌工程,Gremlin 提供了很多很棒的资源。

AWS 故障注入模拟器(AWS Fault Injection Simulator)


最近专注于 AWS 服务,AWS 提供了故障注入模拟器。如果您完全使用 AWS 平台并希望将混沌工程实验引入您的 AWS 环境,AWS FIS 是一个不错的选择。了解有关故障注入测试及其优势的更多信息。

无论您选择哪种工具,您的 CI/CD 管道都是运行和编排混沌工程实验的好地方。

试验您的 CI/CD 管道


随着在系统中建立信心的新方法开始受到关注,CI/CD 管道是协调建立信心步骤的好地方。混沌工程实验非常适合在 CI/CD 管道中运行。最近,Harness 和 Gremlin 创建了一个演示,展示了 CI/CD 管道和 Gremlin Experiments 之间的集成。

可能的艺术是让混沌工程实验的结果影响部署,或者如果部署到较低的环境,让 Harness 作为混沌工程实验和其他自动化测试的协调器。如需完整示例,请前往 Harness 社区了解更多信息。

线束(Harness )在这里提供帮助


Harness 软件交付平台是一个非常强大的平台,专门用于协调建立信任的步骤。 就像在任何实验中一样,混沌工程的一个支柱是有一个基线。 想象一下,您是一个团队的新手,例如 SRE 团队,该团队涵盖了数十个不是您自己编写的应用程序。 首次运行混沌工程测试将需要隔离或启动应用程序和相关基础设施的新发行版,以进行试验,而不会对生产产生影响。

如果您的应用程序不是通过强大的管道部署的,那么创建另一个隔离部署可能与正常部署应用程序的正常潮起潮落一样痛苦。 沿着混沌工程成熟之旅前进,因为混沌工程测试被视为强制覆盖,按照惯例,将它们集成到用于判断调用或故障策略的 Harness 工作流中很简单。

本文:https://jiagoushi.pro/what-chaos-engineering-intro-definition-more

SEO Title
What Is Chaos Engineering? Intro, Definition & More

【混沌工程】故意破坏和混沌工程

Chinese, Simplified

在这一集中,Jason 与加拿大皇家银行的开发者宣传总监 Aaron Clark 聊天。 Aaron 分享了最初在 RBC 担任开发人员并从事早期云开发工作,然后过渡到他作为开发人员倡导者的角色的感觉。 Jason 和 Aaron 讨论了在组织内应用开源原则或“内部资源”的价值。他们的时间以继续教育和如何继续学习的讨论结束。

在本集中,我们将介绍:

  • Aaron 谈到了作为开发人员的起步以及在 RBC 的云开发的早期阶段 (1:05)
  • Aaron 讨论了向开发人员倡导过渡 (12:25)
  • Aaron 确定了他在早期倡导开发人员时所取得的成功 (20:35)
  • Jason 询问如何帮助开发人员完成长期维护项目或“可持续发展” (25:40)
  • Jason 和 Aaron 讨论什么是“内部资源”以及为什么它在组织中很有价值 (29:29)
  • Aaron 回答了“你如何使技能和知识保持最新?”这个问题。 (33:55)
  • Aaron 谈论 RBC 的工作机会 (38:55)

参考链接:

加拿大皇家银行:https://www.rbcroyalbank.com
RBC 的机会:https://jobs.rbc.com/ca/en
成绩单
Aaron:我猜有些 PM 问过我的老板,“所以,Aaron 没有参加我们的平台状态会议,他并没有真正接受门票,也没有参加支持轮换。 Aaron 为云平台团队做了什么?”

杰森:[笑]。

Jason:欢迎收听 Break Things on Purpose,这是一个关于可靠性、学习和构建更好系统的播客。在这一集中,我们与加拿大皇家银行开发者宣传总监 Aaron Clark 进行了交谈。我们与他聊了聊他从开发人员到倡导者的旅程,在组织内应用开源原则(称为内部资源)的力量以及他继续学习的建议。

杰森:欢迎来到这个节目,亚伦。

亚伦:谢谢你邀请我,杰森。我的名字是亚伦克拉克。我是 RBC 的云开发倡导者。那就是加拿大皇家银行。从 2010 年 2 月起,我就在银行工作了……嗯。

Jason:那么,当你第一次加入银行时,你并不是开发者的拥护者?

亚伦:对。因此,我自 2019 年以来一直担任现在的职务。自 2017 年以来,我一直是云计划的一部分。早在 2010 年,我就以 Java 开发人员的身份加入。所以,作为一名开发人员,我的背景对 Java 非常重要。 Java 和 Spring Boot,现在。

我加入了皇家银行众多职能领域之一的一系列 Java 应用程序的工作。银行很大。这是人们有时难以掌握的事情之一。这是一个如此庞大的组织。我们大概有 100,000 名……是的,有 100,000 名员工,其中大约 10,000 名从事技术工作,因此开发人员、开发人员相邻的角色(如业务分析师和 QE)、运营和支持以及所有这些角色。

这是一个大组织。当你加入组织时,这是一件有趣的事情。因此,我加入了一个名为 Risk IT 的小组。我们只构建面向内部的应用程序。我在那里做了一堆东西。

我是一个多面手,我对 DevOps 的所有事情都感兴趣。我在 Risk 中设置了第一批 Hudson 服务器之一——嗯,在银行中,但特别是在 Risk 中——我在一边管理它,因为没有其他人在做,它需要做。在这样做了几年并从事了许多不同的项目之后,我偶尔只是,“我们需要这个项目成功,一开始就有一个良好的基础,所以亚伦,你在这个项目上做了六个月然后你正在做一些不同的事情。”这真的很有趣。同时,我总是担心这样一个问题,如果你不坚持很长时间,你永远不会知道你可能做出的错误决定的后果,因为你不必处理它。

杰森:[笑]。

亚伦:这就像我希望我在这里做出正确决定的另一面。它看起来很不错,人们似乎对此很满意,但我总是担心这一点。就像,在一个角色中工作了几年,你构建了一些东西,然后它在生产中,你正在运行它并且你正在处理,“哦,我做出了这个当时似乎是个好主意的决定.事实证明这是个坏主意。下次不要这样。”如果你不留在一个角色中,你永远不会学到这一点。

当我在风险 IT 部门工作了四到五年,所以我会与一群可能留在这个项目上的团队一起工作,他们会来问我问题。就像,我没有消失。在接下来的几个月或其他任何时间里,我都不会在那个项目上工作。然后我搬到了该组织的另一个部门,比如一个名为 Finance IT 的姊妹组,它运行某种类型的东西——为银行构建和运行总账。或者至少对于部分资本市场而言。

随着组织的移动,它变得模糊。团体合并和分散等等。那个小组,我实际上有一些有趣的东西,当我开始研究更多的东西时,比如云,看着云,银行开始引入云。所以,我仍然在应用程序开发方面,但我对此很感兴趣。我参加过 OSCON 之类的会议,开始听说和了解 Docker、Kubernetes、Spring Boot 之类的东西,我觉得这是一些非常简洁的东西。

我在银行早期的 Hadoop 集群之一上开发基于 Spark 的 ETL 系统。所以,我一直觉得,超级,超级幸运,我做了很多这样的事情,在所有这些新事物在组织中真正新生的时候就开始工作。我也得到了非常支持的领导。所以,就像我正在做的那样——持续集成服务器,它完全在旁边;我参与了一堆重用想法,我们有这个更大的群体;我们正在做很多类似的事情;让我们分享一些图书馆和类似的东西。那是在成为任何,比如,开发者倡导者或任何类似的东西之前,我正在从事这些工作。

基本上,我实际上得到了一年的资金来促进和从事重用活动。那就是——我学到了很多,我犯了很多错误,我现在,比如,告诉我在我目前的角色中做出的一些决定,但我正在做这一切,我几乎把它描述为我有点因为我在这个团队工作,所以对我现有的项目征税,但我还有这件事要做。而且我可能需要花一个上午的时间而不是为您的项目工作,因为我必须为某人维护这台构建机器。我得到了非常支持的领导。他们很棒。

他们认识到这些活动的价值,并没有真正争论我正在从预算中说我应该做的任何事情上抽出时间,这真的很好。所以,我开始这样做,我在金融部门工作,因为云团队开始经历改造——银行最初的新生云团队——我从应用程序开发端做云的事情,但同时在我的团队中,每当有什么令人惊讶的事情被打破,有人遇到紧急情况需要有人介入并聪明地解决问题时,那个人就变成了我。从这个意义上说,我遇到了很多干扰。很高兴成为那个开始工作的人,“哦,这东西需要拯救。帮助我们,亚伦。”

这太妙了;感觉真的很好,对,直到你花了很多时间做这件事,而你不能做你真正感兴趣的事情。所以,我实际上决定搬到云团队工作关于定义我们如何为云构建应用程序的方式,这真的是——这是一个非常好的时机。那是在银行的早期阶段,所以没有人真正知道我们将如何构建应用程序,我们将如何将它们放在云上,这种结构是什么样的?我必须做大量的阅读、研究和向其他人学习。一个关键的事情,比如,一个像银行一样行动缓慢并且在技术选择方面有点规避风险的非常大的组织,人们总是表现得好像这总是一件坏事。

有时是因为我们有时没有采用我们真正能从中获得很多好处的东西,但另一方面,当我们接触到很多这些技术和平台时,一堆锋利的边缘已经被打磨掉了。就像世界上的 Facebook 和 Twitter 一样,他们已经采用了它,他们已经发现了所有这些问题,并且像用胶带一样把它们粘在一起。他们发现,“哦,我们需要在这个系统中内置实际的,比如,安全性”,或者类似的东西,他们已经解决了。所以,当我们谈到它时,其中一些问题已经不存在了。我们不必与他们打交道。

在一个更保守的组织中,这是一个被低估的积极因素。所以,我们认为我们可以从中学到很多东西。当我们研究微服务以及类似 Spring Boot Spring Cloud 时,最初被引入组织的云部分主要围绕 Cloud Foundry。我们正在帮助一些初始应用程序团队构建他们的应用程序,我们可能过度设计了其中一些应用程序,从某种意义上说,我们正在证明构建这些应用程序并不迫切需要的模式。就像,您可能刚刚使用 Web 应用程序和关系数据库完成了它,它会很好。

但我们正在证明一些模式,你如何使用微服务和类似的东西构建更大规模的东西。我们了解了很多关于这样做太早的复杂性,但我们也了解了很多关于如何做到这一点的知识,以便我们可以教其他应用程序团队。这就是我加入的那种团队,我不是云上的平台操作员,但我正在与开发团队合作,与开发团队一起构建东西,以帮助他们学习如何为云构建东西。这是我第一次真正接触到银行的范围和规模。我曾在较小的小组中工作,当您开始与银行的较大部分进行互动时,您开始遇到的一件事就是,有多少孤岛,技术堆栈的多样性那种规模的组织。

比如,我们有使用 Java 的领域,我们有使用 .NET Framework 的领域,我们有很多 Python 的领域,我们有很多 Node 的领域,尤其是当组织开始构建更多的 Web 应用程序时。当你使用 Angular 构建东西并使用 npm 作为前端时,你也在使用 Node 在后端构建东西。无论这是否是一个好的技术选择,很多时候你都是在用你所拥有的东西来构建。即使在 Java 中,我们也会有团队使用 Spring Boot 构建,并且很多团队都在这样做,但是其他人对 Google Guice 感兴趣,所以他们正在构建——而不是 Spring,他们使用 Google Guice 作为他们的依赖注入框架。

或者他们有一个……比如,有大型机,对吧?您拥有庞大的技术堆栈,许多人仍在其中构建 Java EE 应用程序,并试图将其从 Java EE 的旧肮脏时代发展为更好的现代方式。一些技术对话是这样的,“好吧,你可以使用其他技术;没关系,但如果你正在使用它,而我们在这里使用其他东西,我们将无法互相帮助。当我解决问题时,我也无法真正帮助您解决问题。你必须用你的框架自己解决它。”

我曾经和一个在 Java 中使用 Vertex 的团队交谈过,我问他们:“你们为什么使用 Vertex?”他们说,“嗯,这就是我们团队所知道的。”我当时想,“从我们必须交付的意义上说,这是一个很好的技术选择。这就是我们所知道的,所以这就是我们知道我们可以成功的事情,而不是在尝试交付某些东西的同时在工作中实际学习新东西。”如果不是彻底失败,这通常是挑战的秘诀。

杰森:是的。所以,这听起来像是你进来的地方;如果所有这些团队都在做非常不同的事情,对——

亚伦:嗯嗯。

杰森:这有好有坏,对吧?这就是微服务的全部意义在于独立的团队,每个人都解耦,速度更快。但是,利用从一个团队到另一个团队的一些经验,并真正开始分享这些最佳实践,也有巨大的优势——尤其是在 RBC 规模的组织中。我猜这就是你现在在当前角色中发挥作用的地方。

亚伦:是的。这就是我们如何灵活地让人们在标准化的同时做出自己的选择,这样我们就不会出现这种巨大的蔓延,这样我们就可以在事物的基础上再接再厉?这开始是我开始真正参与社区事务并进行开发者宣传的地方。这实际上是如何发生的一部分——这是我非常幸运并且拥有优秀领导者的另一个案例——我作为云平台团队的一员工作,我曾经是一个特殊项目组,几个人离开了;我是最后一个离开的。就像,“好吧,你不能成为自己的部门,所以你是云平台的一部分。”但我不是运营商。我不接受支持轮换。

而且我表面上是在构建工具,但我主要是在做内部资源。这就是 RBC 内部资源社区开始发展的地方。我是innersource 社区的创始成员之一,并开始了这一进程。我们已经为云构建了一堆库,所以这些是内部源代码的第一批项目,我使用 OIDC 维护 Java 和 Spring 库。这有点早于 Spring Security 对 OIDC 的原生支持——所以 Open ID Connect——

我做了很多这样的事情,我支持试图采用该库的应用程序团队,我参与了其他一些早期开发人员体验的事情,你抱怨这件事作为开发人员很糟糕;为什么我们必须这样做?您被邀请参加 VP 的每周例会进行讨论,现在您正忙于尝试修复开发人员体验的某些部分。我正在这样做,我猜有些 PM 问我的老板,“所以,Aaron 没有参加我们的平台状态会议,他并没有真正接受门票,他也没有参加支持轮换。 Aaron 为云平台团队做了什么?”

杰森:[笑]。

Aaron:我的老板说,“嗯,Aaron 还参与了很多其他非常有价值的事情。”此时我正在做的另一件事是主持技术讲座系列演讲,这是一种内部会议式的讲座,我们从组织内部聘请专家,并尝试跨越我们发现的那些孤岛机器学习专家;来解释一下 TensorFlow 是如何工作的。来解释一下 Spark 是如何工作的,为什么它很棒。我们让这些专家来为 RBC 员工做内部演示。我正在这样做,并与我们拥有的联合组织者一起为运行该系列活动提供所有支持工作。

在年底,当他们启动一项新计划以真正专注于我们如何开始促进云采用,而不仅仅是人们到达平台并开始使用它并自己弄清楚时 - 你只能得到到目前为止——我的老板让我坐下来。他说。 “所以,我们真的很喜欢你一直在做的所有事情,所有这些社区的事情和类似的事情,所以我们现在要把它作为你的工作。”这就是我到达那里的方式。这不像我申请成为开发者倡导者。我一边做所有这些事情,突然之间,我 75% 的时间都花在了所有这些副项目上,这成了我的工作。

所以,这并不是最可复制的职业道路,但它是其中之一,比如,参与其中是找到你热衷的领域的好方法。所以,我改变了我的标题。只要您的经理批准,您就可以在我们的某些系统中这样做,所以我将我的头衔从非常通用的“高级技术系统分析师”更改为“开发者倡导者。”那时我开始做更多的研究,了解实际的开发者倡导者做什么,因为我想成为开发者倡导者。我想说我是开发者倡导者。

在组织中最长的时间里,我是公司里唯一拥有这个头衔的人,这很有趣,因为没有人知道该怎么处理我,因为我不像——我是不是——我不是导演,我不是副总裁。就像……但我也不只是一个普通的开发者。哪里——我不适合这个层次结构。这很好,因为人们不再担心什么是标题和类似的东西,他们只是听我说的话。因此,我确实会与开发团队进行设计咨询,确保他们知道自己在做什么,或者在他们开始使用云时意识到一堆陷阱。

我会建立很多样本,很多文档,做很多社区参与,所以去参加我们内部的活动,做很多这样的事情。我已经在做很多内源性的东西——演讲系列——但现在这是我的正式工作,它帮助我跨越了很多这些孤岛,并且非常横向地工作。这是我的工作与普通开发人员的不同部分之一,我的工作是涵盖与云有关的任何事情——至少是我觉得有趣的事情,或者我的老板告诉我需要工作的事情——以及任何地方的任何事情在接触的组织中。所以,一个用 Kubernetes 做事的开发团队,我可以去和他们谈谈。如果他们在资本市场上建立了一些可能有用的东西,我可以说,“嘿,你能把它分享到内部资源中,以便其他人也可以在这项工作的基础上发展吗?”

这真的很棒,因为我与所有这些其他团体建立了所有这些关系。在某种程度上,这也是云程序一开始就需要我做的。我向我的一位朋友解释说,这是我现在的工作。他们就像,“这听起来对你来说是一份完美的工作,因为你是技术人员,但你真的很擅长与人相处。”我想,“我是吗?我想我现在已经做了这么长时间了。”

随着我们越来越多地进行下去,另一部分是因为我与所有这些开发团队交谈,我没有被孤立,我对我正在使用的特定事物没有那么隧道,现在我可以与平台团队交谈并真正代表应用程序开发人员的观点。因为我不是在搭建平台。他们有他们的优先事项,他们有他们不得不担心的事情;我不必处理那个。我的工作是带来应用程序开发人员的视角。这就是我的背景。

我不是操作员;我不关心支持轮换,我不关心平台的一堆琐碎的事情和辛劳。有时,我的工作就是说,嘿,这份文档是善意的。我理解您是如何从平台团队的角度以及您优先考虑并想向人们解释的事情的角度来编写此文档的,但作为应用程序开发人员,我不需要构建在您的平台上运行的东西所需的信息以我能够消费的方式呈现。所以,我也喜欢向平台提供客户反馈说,“这件事很难”,或者,“你要求应用程序团队处理的这件事,他们不想关心关于那个。他们不应该关心这件事。”还有那种东西。

所以,我最终成为了这个人类路由器,有时平台团队会说,“你知道有谁在做这个,谁在使用这个东西吗?”或者找一个应用团队说,“你应该和那边的那个团队谈谈,因为他们也在做同样的事情,或者他们正在为同样的事情苦苦挣扎,你应该合作。”或者,“他们已经解决了这个问题。”因为我不了解我们使用的每一种编程语言,也不了解所有的框架,但我知道我向谁询问了 Python 问题,并且我会派团队去找那个人。然后,当我开始做这个社区工作时,其中的一部分实际上是建立社区。

最大的成功之一是,我们有一个名为“云采用”的 Slack 频道。这是每个人都去问他们的问题的地方,关于我如何做这件事来把东西放在 Cloud Foundry 上,把它放在 Kubernetes 上?我该怎么做呢?我不明白。有时我一整天都在上 Slack 频道,回答问题,非常乐于助人,并试图记录事情,试图了解人们在做什么。

这是我的一整天,有时。花了一段时间才习惯这实际上是来自开发人员背景的成功的一天。我习惯于建造东西,所以我觉得自己很成功,因为我建造了一些我可以向你展示的东西,我今天做到了。然后我会有几天和一群人交谈,但我没有任何东西可以给你看。就像,担任这个角色的困难部分。

但最大的成功之一是我们建立了这个不仅仅是我的社区。其他想要帮助人们的人,他们只是不同开发团队的开发人员,他们会看到我提出问题或回答问题,然后他们会知道答案并插话。当我开始承担更多任务时还有更多其他活动,然后我会去——我会回到 Slack 看看,哦,有一堆问题。哦,事实证明,人们能够自助。从建立社区的角度来看,这就是成功。

现在我已经通过 Tech Talks 完成了几次,包括一些开发人员体验工作,一些云采用工作,我在内部被问到,当我们围绕诸如此类的事情建立新社区时,你如何建立社区现场可靠性工程。我们将如何做到这一点?所以,我明白了——这感觉很奇怪,但这是我现在一直在做的事情之一。就像,这是一个巨大的角色,因为所有的范围。我可以和云中的任何人接触任何东西。

与角色以及银行相关的范围之一是,我们不仅拥有所有这些技术堆栈,而且我们还拥有非常非常多样化的技术敏锐度,其中有一些已经是 Kubernetes 专家的人。无论我做什么,他们都会成功。他们会弄清楚的,因为他们就是那种性格,他们会找到所有的信息。如果有的话,由于作为受监管银行的风险要求和合规要求,我们为管理我们的环境和保护环境而实施的一些限制,这些都会成为阻碍。有时我会解释为什么会有这些东西。有时我同意人们的看法。 “是的,很糟糕。我不想这样做。”

但与此同时,你会有他们只想进来、写代码、回家的人。他们不想考虑除此之外的技术。他们不一定要去自己学习东西。这不是世界末日。对于那些不断学习、不断涉足和修补的人来说,这听起来很奇怪,就像我一样,但你仍然需要人们保持开灯,同时完成所有其他工作。而那些乐于这样做的人,这也很有价值。

因为如果我担任那个角色,我会不高兴。一个快乐的人,比如,这对整个组织都有好处。但是他们需要学习的东西,需要向他们解释的东西,他们需要成功的帮助是不同的。那么,挑战之一就是弄清楚如何应对所有这些客户?有时甚至这些客户的答案是——这是关于我的角色的事情之一——就像定义是客户成功一样。

如果你试图放在云端的应用程序不应该放在云端,我的工作就是告诉你不要把它放在云端。把你放到云端不是我的工作。我希望你成功,而不仅仅是到达那里。我可能会在一个下午把你的东西放到云端,但如果我走开它就坏了,就像,你不知道该怎么做。所以,关于我们如何教人们自助服务,我们如何让我们的内部系统更加自助服务的很多事情,这些都是我现在所关注的事情。

范围这么大,我该如何管理自己的时间?就像,我需要弄清楚我没有将一千件事情向前推进一英寸,但我正在将事情完成。而且我正在学习,在不管理人员的同时,仍然委派并与社区合作,与更广泛的云平台团队合作,围绕我如何放手并帮助其他人做事?

杰森:所以,你提到了我认为非常有趣的东西,对,帮助人们完成目标的目标,对吧?而且我认为这是一件非常有趣的事情,因为我认为,在那个倡导角色中,通常会有这样的想法,比如,我会帮助你摆脱困境,然后你可以继续前进,而不知道他们在哪里'最终走向。这种联系又回到了你之前所说的关于作为一名开发人员开始的事情,你在那里构建东西,你只是,比如,释放它,[笑]你不会想到,你知道,那天二,操作,维护,持续的东西。所以,我很好奇,随着你在事业上的进步,当你从帮助人们中获得更多智慧时,当你帮助人们完成任务时会是什么样子,同样的心态是一个将运行相当长一段时间的应用程序。即使在短期内,你知道,如果这是一个短期的事情,但我觉得在银行,大多数事情可能有点长期存在。你如何平衡呢?您如何处理这个问题,帮助人们完成工作,但同时牢记他们必须这样做——这个应用程序必须保持生存并且必须维护?

Aaron:是的,很多都是——比如,我们使用的术语是可持续发展。其中一部分是消除摩擦,试图让开发人员能够专注于,我猜,行业中经常使用的术语是他们的内部循环。毫不奇怪,银行经常有很多摩擦很大的流程。有很多开放的票,等待事情。这是我与开发团队对话的部分,我问他们:“有哪些困难的事情?你不喜欢的东西是什么?你希望你不必做或关心的事情是什么?”

当你和他们交谈时,其中一些是在字里行间读出来的;与其说是采访他们。就像,任何类型的需求收集,通常不是他们说什么,而是他们说什么然后你看,哦,这就是问题所在;我们如何解决这个问题,以便人们可以到达他们需要去的地方?这种形式的反馈是我对我们建立的系统、我们在平台周围建立的流程、我们所研究的一些工具的一些反馈。我真的非常喜欢 Docker 和 Solomon Hykes 的理念,“包括电池但可拆卸”。我希望开发人员有一个高基线作为起点。

这部分来自我使用 Cloud Foundry 的经验。 Cloud Foundry 为很多事情提供了非常好的开箱即用的开发体验,“我只有一​​个 Web 应用程序。运行它。是 Nginx;这是一些 HTML 页面;我不需要知道所有的细节。让它去吧,把网址给我。”

我希望为应用程序团队提供更多这样的服务,因为他们有很高的工作基线作为起点。每个组织最终都会在他们拥有的地方构建这个——比如 Netflix:Netflix OSS 或带有 Finagle 的 Twitter——在他们拥有的地方,“这是我想要插入的周边部分,每个人都可以作为起点。我们如何提供安全保障?我们如何提供所有这些是应用程序团队主要关注的部分,他们必须做,我们知道他们必须做?”其中一些是只有在云上才开始出现的东西,并试图为应用程序团队提供更多的东西,这样他们就可以专注于业务,只在需要时才进入杂草。

Jason:当你在谈论这些框架时,你知道,拥有人们可以拥有的高质量或高基线工具,对,为他们配备一个不错的工具箱,我猜你的内部资源'正在努力也有助于促进这一点。

亚伦:哦,非常好。随着我们的发展和成熟,我们的内部资源组织,其中很大一部分也是其他团体,他们在那里找到了我们需要的东西。他们会说——它最初是,“我们建造了这个。我们会将其放入内部资源中。”但是你得到的是非常有针对性和特定于他们的团队的东西,也许其他人可以使用它,但如果不稍微弯曲它,他们就无法使用它。

而且我讨厌弯曲软件来适应它。这是其中一件事——在我们拥有现有流程的企业环境中,这是一件非常普遍的事情,我们需要采用它,然后将其弯曲直到它适合我们现有的流程,而不是采用某些工具使用的标准方法,因为我们不想改变我们的流程。这会变得很困难,因为你会遇到奇怪的边缘情况,因为我们弯曲了它,所以它正在做一些奇怪的事情。就像,嗯,那不是它的错。随着我们开始做更多的内部资源,更多的事情真正首先成为内部资源,团队意识到我们需要一起解决这个问题。

让我们一起开始工作,让我们将 API 设计为一个组。 API 设计真的非常非常难。以及我们如何使用共享库或服务来做事。作为一个团队,我们会看到更多这样的事情,更常见的事情是,“嗯,这是我们需要的东西。我们将在内部源中启动它,我们会让一些人使用它,他们将成为我们的测试版客户。我们会在没有真正专门针对应用程序和应用程序团队的需求的情况下通知它。”

因为他们都有特定的需求。这就是“包含但可移动”部分的用武之地。我们如何在我们拥有通用解决方案并且您可以插入您的细节的情况下可扩展地构建东西?而且我们仍然——就像,这不是一个容易的问题。我们仍在解决它,我们仍在努力解决它,我们正在做得更好。

很多问题只是我们如何才能日复一日、年复一年地改进,以使其中一些事情变得更好?甚至我们的持续集成和交付管道到我们的云,所有这些都在不断变化和不断发展。我们支持多种语言;我们支持不同语言的多个版本;我们正在谈论,嘿,我们需要开始采用 Java 17。我们的库或管道还没有这样做,但我们可能应该继续这样做,因为它已经发布了 - 什么 - 快一年了?并且真正致力于分解其中一些我们为当时需要的东西而构建的东西,但现在感觉有点死板。我们如何拉出碎片?

在 log4j CVE 和对行业的广泛影响之后,组织中的一大推动力是我们需要围绕软件供应链做更彻底的工作,围绕知道我们拥有什么,确保我们进行扫描和一切.这就是管道工作的用武之地。我正在就管道问题进行咨询,并提供大量客户反馈;我们有一个团队全职工作。但是做很多这样的事情并尝试为我们需要的东西而构建,但也不要将自己与更广泛的行业隔离开来。就像,从工具的角度来看,我的噩梦是我们限制事物,我们围绕安全或政策或类似的东西做出决定,我们将自己与更广泛的 CNCF 工具生态系统隔离开来,我们不能使用其中任何一个工具。这就像,好吧,现在我们必须自己构建一些东西,或者——我们永远不会像外部社区那样做。或者我们只会有一些糟糕的流程,没有人会高兴,所以要弄清楚所有这些。

杰森:是的。你提到的关于保持速度和拥有这些标准的一件事让我想起,你知道,类似于我之前的经历,基本上,我在一个我们说我们想开放的组织-source,我们使用了开源,这基本上意味着我们分叉了一些东西,然后对它进行了我们自己的奇怪修改。这意味着,就像现在,它不是真正的开源;这就像一个奇怪的、被黑客入侵的东西,你必须不断维护并努力让它与最新的东西保持同步。听起来你在一个更好的位置,但我很好奇,在跟上最新的东西方面,你是怎么做到的,对吧?因为你提到银行,显然慢了一点,采用更成熟的软件,但是你,对,你站在最前沿,你正在努力收集你可以使用的最佳实践和新技术银行,作为一个没有使用最新、最棒的东西的人,你如何做到这一点?您如何使这些技能和知识保持最新?

Aaron:我尝试阅读,我尝试腾出时间阅读 The New Stack 之类的东西,收听有关技术的播客。这是一个非常广泛的行业。我能跟上的只有这么多。这总是可以追溯到很久以前的对话之一,在那里我会与我的老板就我去参加会议的商业主张进行对话,并解释,比如,在一个组织中获取知识的成本是多少?虽然我们可以引入顾问,或者我们可以雇用人员,例如,当您雇用新人时,他们会带来他们先前存在的经验。所以,如果有人进来并且他们知道 Hadoop,他们可以提供有关 Hadoop 解决这个问题的信息和想法吗?也许,也许不是。

如果我对 Hadoop 或 Kubernetes 一无所知,或者……比如在我的工具中使用 Tilt 或 Skaffold 之类的东西,我不想在这个项目上打赌。这是我参加会议的收获之一,现在一切都是虚拟的,我实际上需要留出更多时间来观看视频。就像,没有那个专门的一周是一个问题,我只是断开了连接,我没有处理任何事情。当你在工作时,即使 KubeCon 或 Microsoft Build,我仍然在做我的日常工作,我收到 Slack 消息,而且我不觉得我可以忽略别人。我可能应该花更多的时间,但我如何保持最新状态的一部分。

它真的做了很多阅读和研究,做这样的对话,比如,我们邀请你去哪里的 DX Buzz……我解释了那个事件——它与内部扬声器相邻——我解释说因为我有积压的视频来自我没有看的会议,如果我让其他人和我一起吃午饭来观看这些视频,我必须看视频,因为我正在主持会议来讨论它,现在我至少会看一个月。事实证明,这在组织内部传播知识、与人交谈是一件非常成功的事情。而我做的另一部分,尤其是在工具方面,我仍然在构建东西。尽管我不像以前那样编写代码,但我带来了应用程序开发人员的观点,但我不再每天都编写代码了。

我总是说这会让我很痛苦。它不是。我仍然在想它,当我开始编写代码时,我一直在寻找如何改进这个设置?我怎样才能使用这个工具?我可以试试吗?这是否更好?这对我来说更顺畅,所以我不担心这件事吗?

然后在开发人员体验小组、我们的 DevOps 团队、我们的平台团队中更广泛地传播这些信息,并与这些团队讨论他们使用的东西。就像,我们在一个小组中使用 Argo CD,我没怎么接触过,但我知道他们有很多专业知识,所以和他们谈谈。 “你怎么用这个?这对我有什么好处?我该如何进行这项工作?我也怎么用?”

Jason:我认为这太不可思议了,[笑] 正如你一直在聊天的那样,你提到银行使用或正在使用的工具和技术有很多。两者兼而有之——这很有趣,就像银行里发生了很多事情一样;你如何管理这一切?但我认为这也非常有趣,因为它表明人们对找到正确的解决方案和找到正确的工具很感兴趣,而不是真正超级强烈地与一种特定的工具或一种固定的做事方式结合,我认为这很酷。我们在这里的时间即将结束,所以我确实想问你,在我们签字之前,亚伦,你有什么想要插入的东西,有什么想要宣传的吗?

Aaron:是的,云计划正在招聘大量人员。我们所有的平台团队都有很多职位空缺。我的云采用团队可能有职位空缺。所以,如果你觉得这家银行听起来很有趣——这家银行非常稳定;这总是一件好事——但是银行……关于银行的事情,我最初加入银行时说,“哦,我会在这里两年,我会感到无聊,我会离开,”和现在已经12年了,我还在银行。因为我提到了组织的范围和规模,所以总会有一些有趣的事情发生在某个地方。

所以,如果你对云平台的东西感兴趣,我们有一个巨大的云平台。如果你在——比如,你想做机器学习,我们有一个完整的组织。毫不奇怪,我们在银行拥有大量数据,并且有一个完整的组织来处理各种不同的事情,包括机器学习、深度学习、数据分析、大数据等。就像,如果你认为这很有趣,即使你不是专门在加拿大多伦多,你也可以在组织中找到一个有趣的角色,如果这会让你变得疯狂。

杰森:太棒了。我们将发布我们提到的所有内容的链接,这是一个吨。但是去看看我们吧,gremlin.com/podcast 是你可以找到本集节目说明的地方,我们将提供所有内容的链接。亚伦,非常感谢你加入我们。很高兴有你。

亚伦:非常感谢你邀请我,杰森。我很高兴我们必须这样做。

Jason:有关上述所有信息的链接,请访问我们的网站 gremlin.com/podcast。如果您喜欢这一集,请订阅 Spotify、Apple 播客或您最喜欢的播客平台上的 Break Things on Purpose 播客。我们的主题曲名为 Komiku 的《Battle of Pogs》,可在loyaltyfreakmusic.com 上找到。

本文:https://jiagoushi.pro/podcast-break-things-purpose-developer-advocacy-a…

SEO Title
Podcast: Break Things on Purpose | Developer Advocacy and Innersource with Aaron Clark

【混沌工程】混沌工程原理

Chinese, Simplified

混沌工程是在系统上进行实验的学科,目的是建立对系统承受生产中动荡条件的能力的信心。

大规模分布式软件系统的进步正在改变软件工程的游戏规则。作为一个行业,我们迅速采用提高开发灵活性和部署速度的做法。紧随这些好处之后的一个紧迫问题是:我们对投入生产的复杂系统有多少信心?

即使分布式系统中的所有单个服务都正常运行,这些服务之间的交互也会导致不可预测的结果。不可预测的结果,加上影响生产环境的罕见但具有破坏性的现实世界事件,使这些分布式系统本质上是混乱的。

我们需要在弱点出现在系统范围的异常行为中之前识别它们。系统性弱点可能表现为: 服务不可用时不正确的回退设置;从调整不当的超时重试风暴;当下游依赖收到过多流量时中断;单点故障崩溃时的级联故障;等等。我们必须在最重要的弱点影响生产中的客户之前主动解决它们。我们需要一种方法来管理这些系统中固有的混乱,利用不断提高的灵活性和速度,并对我们的生产部署充满信心,尽管它们代表着复杂性。

一种基于经验的、基于系统的方法可以大规模解决分布式系统中的混乱问题,并建立对这些系统承受现实条件的能力的信心。我们通过在受控实验中观察分布式系统的行为来了解它。我们称之为混沌工程。

实践中的混乱


为了专门解决大规模分布式系统的不确定性,混沌工程可以被认为是促进实验以发现系统弱点。这些实验遵循四个步骤:

  • 首先将“稳态”定义为系统的一些可测量的输出,表明正常行为。
  • 假设这种稳定状态将在对照组和实验组中继续存在。
  • 引入反映现实世界事件的变量,例如服务器崩溃、硬盘驱动器故障、网络连接中断等。
  • 尝试通过寻找对照组和实验组之间的稳态差异来反驳该假设。

破坏稳定状态越难,我们对系统行为的信心就越大。如果发现了一个弱点,我们现在就有了一个改进目标,以便在该行为在整个系统中显现之前进行改进。

高级原理


以下原理描述了混沌工程的理想应用,应用于上述实验过程。遵循这些原则的程度与我们对大规模分布式系统的信心密切相关。

围绕稳态行为建立假设


关注系统的可测量输出,而不是系统的内部属性。在短时间内对该输出的测量构成了系统稳定状态的代表。整个系统的吞吐量、错误率、延迟百分位数等都可以是代表稳态行为的感兴趣的指标。通过在实验期间关注系统行为模式,Chaos 验证系统确实有效,而不是试图验证它是如何工作的。

改变现实世界的事件


混沌变量反映了现实世界的事件。通过潜在影响或估计频率对事件进行优先级排序。考虑与硬件故障(如服务器死亡)、软件故障(如格式错误的响应)以及非故障事件(如流量激增或扩展事件)相对应的事件。任何能够破坏稳态的事件都是混沌实验中的潜在变量。

在生产环境中运行实验


系统的行为因环境和流量模式而异。由于利用率的行为随时可能发生变化,因此对真实流量进行采样是可靠捕获请求路径的唯一方法。为了保证系统运行方式的真实性以及与当前部署系统的相关性,Chaos 强烈倾向于直接在生产流量上进行试验。

自动化实验以连续运行


手动运行实验是劳动密集型的,最终是不可持续的。自动化实验并连续运行它们。混沌工程将自动化构建到系统中,以驱动编排和分析。

最小化爆炸半径


在生产中进行试验有可能导致不必要的客户痛苦。虽然必须考虑一些短期的负面影响,但混沌工程师有责任和义务确保将实验的后果最小化并加以控制。

混沌工程是一种强大的实践,它已经改变了世界上一些最大规模运营中软件的设计和工程方式。在其他实践涉及速度和灵活性的地方,Chaos 专门解决了这些分布式系统中的系统性不确定性。混沌原则为大规模快速创新提供信心,并为客户提供他们应得的高质量体验。

本文:https://jiagoushi.pro/principles-chaos-engineering

SEO Title
PRINCIPLES OF CHAOS ENGINEERING