标签 DevOps 下的文章

让 DevOps 少一点,OpsDev 多一点。

在这个 DevOps 世界中,看起来开发(Dev)这一半成为了关注的焦点,而运维(Ops)则是这个关系中被遗忘的另一半。这几乎就好像是领头的开发告诉尾随的运维做什么,几乎所有的“运维”都是开发说要做的。因此,运维被抛到后面,降级到了替补席上。

我想看到更多的 OpsDev。因此,让我们来看看 Ansible 在日常的运维中可以帮助你什么。

 title=

我选择在 Ansible Tower 中展示这些方案,因为我认为用户界面 (UI) 可以增色大多数的任务。如果你想模拟测试,你可以在 Tower 的上游开源版本 AWX 中测试它。

管理用户

在大规模环境中,你的用户将集中在活动目录或 LDAP 等系统中。但我敢打赌,仍然存在许多包含大量的静态用户的全负荷环境。Ansible 可以帮助你将这些分散的环境集中到一起。社区已为我们解决了这个问题。看看 Ansible Galaxy 中的 users 角色。

这个角色的聪明之处在于它允许我们通过数据管理用户,而无需更改运行逻辑。

 title=

通过简单的数据结构,我们可以在系统上添加、删除和修改静态用户。这很有用。

管理 sudo

提权有多种形式,但最流行的是 sudo。通过每个 usergroup 等离散文件来管理 sudo 相对容易。但一些人对给予特权感到紧张,并倾向于有时限地给予提权。因此下面是一种方案,它使用简单的 at 命令对授权访问设置时间限制。

 title=

管理服务

给入门级运维团队提供菜单以便他们可以重启某些服务不是很好吗?看下面!

 title=

管理磁盘空间

这有一个简单的角色,可在特定目录中查找字节大于某个大小的文件。在 Tower 中这么做时,启用回调有额外的好处。想象一下,你的监控方案发现文件系统已超过 X% 并触发 Tower 中的任务以找出是什么文件导致的。

 title=

调试系统性能问题

这个角色相当简单:它运行一些命令并打印输出。细节在最后输出,让你 —— 系统管理员快速浏览一眼。另外可以使用 正则表达式 在输出中找到某些条件(比如说 CPU 占用率超过 80%)。

 title=

总结

我已经录制了这五个任务的简短视频。你也可以在 Github 上找到所有代码


via: https://opensource.com/article/19/8/ops-tasks-ansible

作者:Mark Phillips 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

如果你是 DevOps 新人,请查看这 5 个步骤来构建你的第一个 DevOps 流水线。

DevOps 已经成为解决软件开发过程中出现的缓慢、孤立或者其他故障的默认方式。但是当你刚接触 DevOps 并且不确定从哪开始时,就意义不大了。本文探索了什么是 DevOps 流水线并且提供了创建它的 5 个步骤。尽管这个教程并不全面,但可以给你以后上手和扩展打下基础。首先,插入一个小故事。

我的 DevOps 之旅

我曾经在花旗集团的云小组工作,开发 Infrastructure as a Service 基础设施即服务网页应用来管理花旗的云基础设施,但我经常对研究如何让开发流水线更加高效以及如何带给团队积极的文化感兴趣。我在 Greg Lavender 推荐的书中找到了答案。Greg Lavender 是花旗的云架构和基础设施工程(即 Phoenix 项目)的 CTO。这本书尽管解释的是 DevOps 原理,但它读起来像一本小说。

书后面的一张表展示了不同公司部署在发布环境上的频率:

公司部署频率
Amazon23,000 次/天
Google5,500 次/天
Netflix500 次/天
Facebook1 次/天
Twitter3 次/周
典型企业1 次/9 个月

Amazon、Google、Netflix 怎么能做到如此之频繁?那是因为这些公司弄清楚了如何去实现一个近乎完美的 DevOps 流水线。

但在花旗实施 DevOps 之前,情况并非如此。那时候,我的团队拥有不同 构建阶段 stage 的环境,但是在开发服务器上的部署非常手工。所有的开发人员都只能访问一个基于 IBM WebSphere Application 社区版的开发环境服务器。问题是当多个用户同时尝试部署时,服务器就会宕机,因此开发人员在部署时就得互相通知,这一点相当痛苦。此外,还存在代码测试覆盖率低、手动部署过程繁琐以及无法根据定义的任务或用户需求跟踪代码部署的问题。

我意识到必须做些事情,同时也找到了一个有同样感受的同事。我们决定合作去构建一个初始的 DevOps 流水线 —— 他设置了一个虚拟机和一个 Tomcat 服务器,而我则架设了 Jenkins,集成了 Atlassian Jira、BitBucket 和代码覆盖率测试。这个业余项目非常成功:我们近乎全自动化了开发流水线,并在开发服务器上实现了几乎 100% 的正常运行,我们可以追踪并改进代码覆盖率测试,并且 Git 分支能够与部署任务和 jira 任务关联在一起。此外,大多数用来构建 DevOps 所使用的工具都是开源的。

现在我意识到了我们的 DevOps 流水线是多么的原始,因为我们没有利用像 Jenkins 文件或 Ansible 这样的高级设置。然而,这个简单的过程运作良好,这也许是因为 Pareto 原则(也被称作 80/20 法则)。

DevOps 和 CI/CD 流水线的简要介绍

如果你问一些人,“什么是 DevOps?”,你或许会得到一些不同的回答。DevOps,就像敏捷,已经发展到涵盖着诸多不同的学科,但大多数人至少会同意这些:DevOps 是一个软件开发实践或一个 软件开发生命周期 software development lifecycle (SDLC),并且它的核心原则是一种文化上的变革 —— 开发人员与非开发人员呼吸着同一片天空的气息,之前手工的事情变得自动化;每个人做着自己擅长的事;同一时间的部署变得更加频繁;吞吐量提升;灵活度增加。

虽然拥有正确的软件工具并非实现 DevOps 环境所需的唯一东西,但一些工具却是必要的。最关键的一个便是持续集成和持续部署(CI/CD)。在流水线环境中,拥有不同的构建阶段(例如:DEV、INT、TST、QA、UAT、STG、PROD),手动的工作能实现自动化,开发人员可以实现高质量的代码,灵活而且大量部署。

这篇文章描述了一个构建 DevOps 流水线的五步方法,就像下图所展示的那样,使用开源的工具实现。

 title=

闲话少说,让我们开始吧。

第一步:CI/CD 框架

首先你需要的是一个 CI/CD 工具,Jenkins,是一个基于 Java 的 MIT 许可下的开源 CI/CD 工具,它是推广 DevOps 运动的工具,并已成为了 事实标准 de facto standard

所以,什么是 Jenkins?想象它是一种神奇的万能遥控,能够和许多不同的服务器和工具打交道,并且能够将它们统一安排起来。就本身而言,像 Jenkins 这样的 CI/CD 工具本身是没有用的,但随着接入不同的工具与服务器时会变得非常强大。

Jenkins 仅是众多构建 DevOps 流水线的开源 CI/CD 工具之一。

名称许可证
JenkinsCreative Commons 和 MIT
Travis CIMIT
CruiseControlBSD
BuildbotGPL
Apache GumpApache 2.0
CabieGNU

下面就是使用 CI/CD 工具时 DevOps 看起来的样子。

 title=

你的 CI/CD 工具在本地主机上运行,但目前你还不能够做些别的。让我们紧随 DevOps 之旅的脚步。

第二步:源代码控制管理

验证 CI/CD 工具可以执行某些魔术的最佳(也可能是最简单)方法是与源代码控制管理(SCM)工具集成。为什么需要源代码控制?假设你在开发一个应用。无论你什么时候构建应用,无论你使用的是 Java、Python、C++、Go、Ruby、JavaScript 或任意一种语言,你都在编程。你所编写的程序代码称为源代码。在一开始,特别是只有你一个人工作时,将所有的东西放进本地文件夹里或许都是可以的。但是当项目变得庞大并且邀请其他人协作后,你就需要一种方式来避免共享代码修改时的合并冲突。你也需要一种方式来恢复一个之前的版本——备份、复制并粘贴的方式已经过时了。你(和你的团队)想要更好的解决方式。

这就是 SCM 变得不可或缺的原因。SCM 工具通过在仓库中保存代码来帮助进行版本控制与多人协作。

尽管这里有许多 SCM 工具,但 Git 是最标准恰当的。我极力推荐使用 Git,但如果你喜欢这里仍有其他的开源工具。

名称许可证
GitGPLv2 & LGPL v2.1
SubversionApache 2.0
Concurrent Versions System (CVS)GNU
VestaLGPL
MercurialGNU GPL v2+

拥有 SCM 之后,DevOps 流水线看起来就像这样。

 title=

CI/CD 工具能够自动化进行源代码检入检出以及完成成员之间的协作。还不错吧?但是,如何才能把它变成可工作的应用程序,使得数十亿人来使用并欣赏它呢?

第三步:自动化构建工具

真棒!现在你可以检出代码并将修改提交到源代码控制,并且可以邀请你的朋友就源代码控制进行协作。但是到目前为止你还没有构建出应用。要想让它成为一个网页应用,必须将其编译并打包成可部署的包或可执行程序(注意,像 JavaScript 或 PHP 这样的解释型编程语言不需要进行编译)。

于是就引出了自动化构建工具。无论你决定使用哪一款构建工具,它们都有一个共同的目标:将源代码构建成某种想要的格式,并且将清理、编译、测试、部署到某个位置这些任务自动化。构建工具会根据你的编程语言而有不同,但这里有一些通常使用的开源工具值得考虑。

名称许可证编程语言
MavenApache 2.0Java
AntApache 2.0Java
GradleApache 2.0Java
BazelApache 2.0Java
MakeGNUN/A
GruntMITJavaScript
GulpMITJavaScript
BuildrApacheRuby
RakeMITRuby
A-A-PGNUPython
SConsMITPython
BitBakeGPLv2Python
CakeMITC#
ASDFExpat (MIT)LISP
CabalBSDHaskell

太棒了!现在你可以将自动化构建工具的配置文件放进源代码控制管理系统中,并让你的 CI/CD 工具构建它。

 title=

一切都如此美好,对吧?但是在哪里部署它呢?

第四步:网页应用服务器

到目前为止,你有了一个可执行或可部署的打包文件。对任何真正有用的应用程序来说,它必须提供某种服务或者接口,所以你需要一个容器来发布你的应用。

对于网页应用,网页应用服务器就是容器。应用程序服务器提供了环境,让可部署包中的编程逻辑能够被检测到、呈现界面,并通过打开套接字为外部世界提供网页服务。在其他环境下你也需要一个 HTTP 服务器(比如虚拟机)来安装服务应用。现在,我假设你将会自己学习这些东西(尽管我会在下面讨论容器)。

这里有许多开源的网页应用服务器。

名称协议编程语言
TomcatApache 2.0Java
JettyApache 2.0Java
WildFlyGNU Lesser PublicJava
GlassFishCDDL & GNU Less PublicJava
Django3-Clause BSDPython
TornadoApache 2.0Python
GunicornMITPython
Python PasteMITPython
RailsMITRuby
Node.jsMITJavascript

现在 DevOps 流水线差不多能用了,干得好!

 title=

尽管你可以在这里停下来并进行进一步的集成,但是代码质量对于应用开发者来说是一件非常重要的事情。

第五步:代码覆盖测试

实现代码测试件可能是另一个麻烦的需求,但是开发者需要尽早地捕捉程序中的所有错误并提升代码质量来保证最终用户满意度。幸运的是,这里有许多开源工具来测试你的代码并提出改善质量的建议。甚至更好的,大部分 CI/CD 工具能够集成这些工具并将测试过程自动化进行。

代码测试分为两个部分:“代码测试框架”帮助进行编写与运行测试,“代码质量改进工具”帮助提升代码的质量。

代码测试框架

名称许可证编程语言
JUnitEclipse Public LicenseJava
EasyMockApacheJava
MockitoMITJava
PowerMockApache 2.0Java
PytestMITPython
HypothesisMozillaPython
ToxMITPython

代码质量改进工具

名称许可证编程语言
CoberturaGNUJava
CodeCoverEclipse Public (EPL)Java
Coverage.pyApache 2.0Python
EmmaCommon Public LicenseJava
JaCoCoEclipse Public LicenseJava
HypothesisMozillaPython
ToxMITPython
JasmineMITJavaScript
KarmaMITJavaScript
MochaMITJavaScript
JestMITJavaScript

注意,之前提到的大多数工具和框架都是为 Java、Python、JavaScript 写的,因为 C++ 和 C# 是专有编程语言(尽管 GCC 是开源的)。

现在你已经运用了代码覆盖测试工具,你的 DevOps 流水线应该就像教程开始那幅图中展示的那样了。

可选步骤

容器

正如我之前所说,你可以在虚拟机(VM)或服务器上发布你的应用,但是容器是一个更好的解决方法。

什么是容器?简要的介绍就是 VM 需要占用操作系统大量的资源,它提升了应用程序的大小,而容器仅仅需要一些库和配置来运行应用程序。显然,VM 仍有重要的用途,但容器对于发布应用(包括应用程序服务器)来说是一个更为轻量的解决方式。

尽管对于容器来说也有其他的选择,但是 Docker 和 Kubernetes 更为广泛。

名称许可证
DockerApache 2.0
KubernetesApache 2.0

了解更多信息,请查看 Opensource.com 上关于 Docker 和 Kubernetes 的其它文章:

中间件自动化工具

我们的 DevOps 流水线大部分集中在协作构建与部署应用上,但你也可以用 DevOps 工具完成许多其他的事情。其中之一便是利用它实现 基础设施管理 Infrastructure as Code (IaC)工具,这也是熟知的中间件自动化工具。这些工具帮助完成中间件的自动化安装、管理和其他任务。例如,自动化工具可以用正确的配置下拉应用程序,例如网页服务器、数据库和监控工具,并且部署它们到应用服务器上。

这里有几个开源的中间件自动化工具值得考虑:

名称许可证
AnsibleGNU Public
SaltStackApache 2.0
ChefApache 2.0
PuppetApache or GPL

获取更多中间件自动化工具,查看 Opensource.com 上的其它文章:

之后的发展

这只是一个完整 DevOps 流水线的冰山一角。从 CI/CD 工具开始并且探索其他可以自动化的东西来使你的团队更加轻松的工作。并且,寻找开源通讯工具可以帮助你的团队一起工作的更好。

发现更多见解,这里有一些非常棒的文章来介绍 DevOps :

使用开源 agile 工具来集成 DevOps 也是一个很好的主意:


via: https://opensource.com/article/19/4/devops-pipeline

作者:Bryant Son 选题:lujun9972 译者:LuMing 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

无论你是刚毕业的大学生,还是想在职业中寻求进步的经验丰富的 IT 专家,这些提示都可以帮你成为 DevOps 工程师。

DevOps 工程是一个备受称赞的热门职业。不管你是刚毕业正在找第一份工作,还是在利用之前的行业经验的同时寻求学习新技能的机会,本指南都能帮你通过正确的步骤成为 DevOps 工程师

让自己沉浸其中

首先学习 DevOps 的基本原理、实践以及方法。在使用工具之前,先了解 DevOps 背后的“为什么”。DevOps 工程师的主要目标是在整个软件开发生命周期(SDLC)中提高速度并保持或提高质量,以提供最大的业务价值。阅读文章、观看 YouTube 视频、参加当地小组聚会或者会议 —— 成为热情的 DevOps 社区中的一员,在那里你将从先行者的错误和成功中学习。

考虑你的背景

如果你有从事技术工作的经历,例如软件开发人员、系统工程师、系统管理员、网络运营工程师或者数据库管理员,那么你已经拥有了广泛的见解和有用的经验,它们可以帮助你在未来成为 DevOps 工程师。如果你在完成计算机科学或任何其他 STEM(LCTT 译注:STEM 是 科学 Science 技术 Technology 工程 Engineering 数学 Math 四个学科的首字母缩略字)领域的学业后刚开始职业生涯,那么你将拥有在这个过渡期间需要的一些基本踏脚石。

DevOps 工程师的角色涵盖了广泛的职责。以下是企业最有可能使用他们的三种方向:

  • 偏向于开发(Dev)的 DevOps 工程师,在构建应用中扮演软件开发的角色。他们日常工作的一部分是利用持续集成 / 持续交付(CI/CD)、共享仓库、云和容器,但他们不一定负责构建或实施工具。他们了解基础架构,并且在成熟的环境中,能将自己的代码推向生产环境。
  • 偏向于运维技术(Ops)的 DevOps 工程师,可以与系统工程师或系统管理员相比较。他们了解软件的开发,但并不会把一天的重心放在构建应用上。相反,他们更有可能支持软件开发团队实现手动流程的自动化,并提高人员和技术系统的效率。这可能意味着分解遗留代码,并用不太繁琐的自动化脚本来运行相同的命令,或者可能意味着安装、配置或维护基础结构和工具。他们确保为任何有需要的团队安装可使用的工具。他们也会通过教团队如何利用 CI / CD 和其他 DevOps 实践来帮助他们。
  • 网站可靠性工程师(SRE),就像解决运维和基础设施的软件工程师。SRE 专注于创建可扩展、高可用且可靠的软件系统。

在理想的世界中,DevOps 工程师将了解以上所有领域;这在成熟的科技公司中很常见。然而,顶级银行和许多财富 500 强企业的 DevOps 职位通常会偏向开发(Dev)或运营(Ops)。

要学习的技术

DevOps 工程师需要了解各种技术才能有效完成工作。无论你的背景如何,请从作为 DevOps 工程师需要使用和理解的基本技术开始。

操作系统

操作系统是一切运行的地方,拥有相关的基础知识十分重要。Linux 是你最有可能每天使用的操作系统,尽管有的组织会使用 Windows 操作系统。要开始使用,你可以在家中安装 Linux,在那里你可以随心所欲地中断,并在此过程中学习。

脚本

接下来,选择一门语言来学习脚本编程。有很多语言可供选择,包括 Python、Go、Java、Bash、PowerShell、Ruby 和 C / C++。我建议从 Python 开始,因为它相对容易学习和解释,是最受欢迎的语言之一。Python 通常是遵循面向对象编程(OOP)的准则编写的,可用于 Web 开发、软件开发以及创建桌面 GUI 和业务应用程序。

学习了 LinuxPython 之后,我认为下一个该学习的是云计算。基础设施不再只是“运维小哥”的事情了,因此你需要接触云平台,例如 AWS 云服务、Azure 或者谷歌云平台。我会从 AWS 开始,因为它有大量免费学习工具,可以帮助你降低作为开发人员、运维人员,甚至面向业务的部门的任何障碍。事实上,你可能会被它提供的东西所淹没。考虑从 EC2、S3 和 VPC 开始,然后看看你从其中想学到什么。

编程语言

如果你对 DevOps 的软件开发充满热情,请继续提高你的编程技能。DevOps 中的一些优秀和常用的编程语言和你用于脚本编程的相同:Python、Go、Java、Bash、PowerShell、Ruby 和 C / C++。你还应该熟悉 Jenkins 和 Git / Github,你将会在 CI / CD 过程中经常使用到它们。

容器

最后,使用 Docker 和编排平台(如 Kubernetes)等工具开始学习容器化。网上有大量的免费学习资源,大多数城市都有本地的线下小组,你可以在友好的环境中向有经验的人学习(还有披萨和啤酒哦!)。

其他的呢?

如果你缺乏开发经验,你依然可以通过对自动化的热情,提高效率,与他人协作以及改进自己的工作来参与 DevOps。我仍然建议学习上述工具,但重点不要放在编程 / 脚本语言上。了解基础架构即服务、平台即服务、云平台和 Linux 会非常有用。你可能会设置工具并学习如何构建具有弹性和容错能力的系统,并在编写代码时利用它们。

找一份 DevOps 的工作

求职过程会有所不同,具体取决于你是否一直从事技术工作,是否正在进入 DevOps 领域,或者是刚开始职业生涯的毕业生。

如果你已经从事技术工作

如果你正在从一个技术领域转入 DevOps 角色,首先尝试在你当前的公司寻找机会。你能通过和其他的团队一起工作来重新掌握技能吗?尝试跟随其他团队成员,寻求建议,并在不离开当前工作的情况下获得新技能。如果做不到这一点,你可能需要换另一家公司。如果你能从上面列出的一些实践、工具和技术中学习,你将能在面试时展示相关知识从而占据有利位置。关键是要诚实,不要担心失败。大多数招聘主管都明白你并不知道所有的答案;如果你能展示你一直在学习的东西,并解释你愿意学习更多,你应该有机会获得 DevOps 的工作。

如果你刚开始职业生涯

申请雇用初级 DevOps 工程师的公司的空缺机会。不幸的是,许多公司表示他们希望寻找更富有经验的人,并建议你在获得经验后再申请该职位。这是“我们需要经验丰富的人”的典型,令人沮丧的场景,并且似乎没人愿意给你第一次机会。

然而,并不是所有求职经历都那么令人沮丧;一些公司专注于培训和提升刚从大学毕业的学生。例如,我工作的 MThree 会聘请应届毕业生并且对其进行 8 周的培训。当完成培训后,参与者们可以充分了解到整个 SDLC,并充分了解它在财富 500 强公司环境中的运用方式。毕业生被聘为 MThree 的客户公司的初级 DevOps 工程师 —— MThree 在前 18 - 24 个月内支付全职工资和福利,之后他们将作为直接雇员加入客户。这是弥合从大学到技术职业的间隙的好方法。

总结

转职成 DevOps 工程师的方法有很多种。这是一条非常有益的职业路线,可能会让你保持繁忙和挑战 — 并增加你的收入潜力。


via: https://opensource.com/article/19/7/how-transition-career-devops-engineer

作者:Conor Delanbanque 选题:lujun9972 译者:beamrolling 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

仪表板可以帮助 DevOps 团队观测和监控系统,以提高性能。

指标仪表板帮助 DevOps 团队监控整个 DevOps 平台,以便实时响应 议题 issue 。在处理生产环境宕机或者应用服务中断等情况时,指标仪表板显得尤为重要。

DevOps 仪表板聚合了多个监测工具的指标,为开发和运维团队生成监控报告。它还允许团队跟踪多项指标,例如服务部署时间、程序 bug、报错信息、工作项、待办事项等等。

下面三种指标仪表板可以帮助 DevOps 团队监测系统,改善服务性能。

敏捷项目管理仪表板

这种类型的仪表板为 DevOps 团队的工作项提供可视化视图,优化敏捷项目的工作流。有利于提高团队协作效率,对工作进行可视化并提供灵活的视图 —— 就像我们过去在白板上使用便利贴来共享项目进度、 议题 issue 和待办事项一样。

  • Kanban boards 允许 DevOps 团队创建卡片、标签、任务和栏目,便于持续交付敏捷项目。
  • Burndown charts 对指定时间段内未完成的工作或待办事项提供可视化视图,并记录团队当前的效率和轨迹,这些指标通常用于敏捷项目和 DevOps 项目管理。
  • Jira boards 帮助 DevOps 团队创建议题、计划迭代并生成团队总结。这些灵活的仪表板还能帮助团队综合考虑并确定个人和团队任务的优先级;实时查看、汇报和跟踪正在进行的工作;并提高团队绩效。
  • GitHub project boards 帮助确定团队任务的优先级。它们还支持拉取请求,因此团队成员可以方便地提交 DevOps 项目相关的信息。

应用程序监控仪表板

开发者负责优化应用和服务的性能,并开发新功能。应用程序监控面板则帮助开发者在 持续集成/持续开发 CI / CD 流程下,加快修复 bug、增强程序健壮性、发布安全修丁的进度。另外,这些可视化仪表板有利于查看请求模式、请求耗时、报错和网络拓扑信息。

  • Jaeger 帮助开发人员跟踪请求数量、请求响应时间等。对于分布式网络系统上的云原生应用程序,它还使用 Istio 服务网格加强了监控和跟踪。
  • OpenCensus 帮助团队查看运行应用程序的主机上的数据,它还提供了一个可插拔的导出系统,用于将数据导出到数据中心。

DevOps 平台监控面板

你可能使用多种技术和工具在云上或本地构建 DevOps 平台,但 Linux 容器管理工具(如 Kubernetes 和 OpenShift )更利于搭建出一个成功的 DevOps 平台。因为 Linux 容器的不可变性和可移植性使得应用程序从开发环境到生产环境的编译、测试和部署变得更快更容易。

DevOps 平台监控仪表板帮助运营团队从机器/节点故障和服务报错中收集各种按时序排列的数据,用于编排应用程序容器和基于软件的基础架构,如网络(SDN)和存储(SDS)。这些仪表板还能可视化多维数据格式,方便地查询数据模式。

  • Prometheus dashboards 从平台节点或者运行中的容器化应用中收集指标。帮助 DevOps 团队构建基于指标的监控系统和仪表板,监控微服务的客户端/服务器工作负载,及时识别出异常节点故障。
  • Grafana boards 帮助收集事件驱动的各项指标,包括服务响应持续时间、请求量、 客户端/服务器 client/server 工作负载、网络流量等,并提供了可视化面板。DevOps 团队可以通过多种方式分享指标面板,也可以生成编码的当前监控数据快照分享给其他团队。

总结

这些仪表板提供了可视化的工作流程,能够发现团队协作、应用程序交付和平台状态中的各种问题。它们帮助开发团队增强其在快速应用交付、安全运行和自动化 CI/CD 等领域的能力。


via: https://opensource.com/article/19/7/dashboards-devops-teams

作者:Daniel Oh 选题:lujun9972 译者:hello-wn 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

DevSecOps 的实践之旅开始于 DevSecOps 增权、赋能和培养。下面就介绍如何开始学习使用 DevSecOps。

Stephen Streichsbier 说过: DevSecOps 使得组织可以用 DevOps 的速度发布内在安全的软件。

DevSecOps 是一场关于 DevOps 概念实践或艺术形式的变革。为了更好理解 DevSecOps,你应该首先理解 DevOps 的含义。

DevOps 起源于通过合并开发和运维实践,消除隔离,统一关注点,提升团队和产品的效率和性能。它是一种注重于构建容易维护和易于平常自动运营的产品和服务的新型协作方式。

安全在很多团队中都是常见的隔离点。安全的核心关注点是保护团队,而有时这也意味着创建延缓新服务或是新产品发布的障碍或策略,用于保障任何事都能被很好的理解和安全的执行,并且没有给团队带来不必要的风险。

因为安全隔离点方面的明显特征和它可能带来的摩擦,开发和运维有时会避开安全要求以满足客观情况。在一些公司,这种隔离形成了一种产品安全完全是安全团队责任的期望,并取决于安全团队去寻找产品的安全缺陷或是可能带来的问题。

DevSecOps 看起来是通过给开发或是运维角色加强或是建立安全意识,或是在产品团队中引入一个安全工程师角色,在产品设计中找到安全问题,从而把安全要求汇聚在 Devops 中。

这样使得公司能更快发布和更新产品,并且充分相信安全已经嵌入产品中。

坚固的软件哪里适用 DevSecOps?

建造坚固的软件是 DevOps 文化的一个层面而不是一个特别的实践,它完善和增强了 DevSecOps 实践。想想一款坚固的软件就像是某些经历过残酷战斗过程的事物。

有必要指出坚固的软件并不是 100% 安全可靠的(虽然它可能最终是在某些方面)。然而,它被设计成可以处理大部分被抛过来的问题。

践行坚固软件最重要的原则是促进竞争、实践、可控的失败与合作。

你该如何开始学习 DevSecOps ?

开始实践 DevSecOps 涉及提升安全需求和在开发过程中尽可能早的阶段进行实践。它最终在公司文化上提升了安全的重要性,使得安全成为所有人的责任,而并不只是安全团队的责任。

你可能在团队中听说过“ 左上升 shift left ”这个词,如果你把开发周期线扁平化到一条横线上,以包括产品变革的的关键时期:从初始化到设计、建造、测试以及最终的运行,安全的目的就是尽早的参与进来。这使得风险可以在设计中能更好的评估、交流和减轻。“左提升”的含义是指促使安全能在开发周期线上更往左走。

这个过程始于三个关键要素:

  • 增权 empowerment
  • 赋能 enablement
  • 培养 education

增权,在我看来,是关于释放控制权以及使得团队(在理性分析下)做出独立决定而不用害怕失败或影响。这个过程的唯一告诫信息就是要严格的做出明智的决定(不要比这更低要求)。

为了实现增权,商务和行政支持(通过内部销售、展示来建立,通过建立矩阵来展示这项投资的回报)是打破历史障碍和割裂的团队的关键。合并安全人员到开发和运维团队中,提升交流和透明度有助于开始 DevSecOps 之旅。

这个整合和移动使得团队只关注单一的结果:打造一个他们共同负责的产品,让开发和安全人员相互依赖合作。这将引领你们共同走向增权。这是产品研发团队的共同责任,并保证每个可分割的产品都保持其安全性。

赋能涉及正确的使用掌握在团队手中的工具和资源。这是建立一种通过论坛、维基、信息聚合的知识分享文化。

打造一种注重自动化、重复任务应该编码来尽可能减少以后的操作并增强安全性的理念。这种场景不仅仅是提供知识,而是让这种知识能够通过多种渠道和媒介(通过某些工具)可获取,以便它可以被团队或是个人以他喜欢的方式去消化和分享。当团队成员正在编码时一种媒介可能工作的很好,而当他们在进行中时另一种可能更好。让工具简单可用,让团队用上它们。

不同的 DevSecOps 团队有不同的喜好,因此允许他们尽可能的保持独立。这是一个微妙的平衡工作,因为你确实希望实现规模经济和产品间共享的能力。在选择中协作和参与,并更新工具方法有助于减少使用中的障碍。

最后,也可能是最重要的,DevSecOps 是有关训练和兴趣打造。聚会、社交或是组织中通常的报告会都是让同事们教学和分享他们的知识的很棒的方式。有时,这些会突出其他人可能没有考虑过的共同挑战、顾虑或风险。分享和教学也是一种高效的学习和指导团队的方法。

在我个人经验中,每个团队的文化都是独一无二的,因此你不能用一种“普适”的方法。走进你的团队并找到他们想要使用的工具方法。尝试不同的论坛和聚会并找出最适用于你们文化的方式。寻找反馈并询问团队如何工作,他们喜欢什么以及对应的原因。适应和学习,保持乐观,不要停止尝试,你们将会有所收获。


via: https://opensource.com/article/19/1/what-devsecops

作者:Brett Hunoldt 选题:lujun9972 译者:PandaWizard 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

人和流程比在解决的业务问题的任何技术“银弹”更重要,且需要花更多的时间。

 title=

今天的许多 IT 专业人士都在努力适应变化和扰动。这么说吧,你是否正在努力适应变化?你觉得不堪重负吗?这并不罕见。今天,IT 的现状还不够好,所以需要不断尝试重新自我演进。

凭借 30 多年的IT综合经验,我们见证了人员与关系对于 IT 企业提高效率和帮助企业蓬勃发展的重要性。但是,在大多数情况下,我们关于 IT 解决方案的对话始于技术,而不是从人员和流程开始。寻找“银弹”来解决业务和 IT 挑战的倾向过于普遍。但你不能想着可以买到创新、DevOps 或有效的团队和工作方式;他们需要得到培养,支持和引导。

由于扰动如此普遍,并且对变革速度存在如此迫切的需求,我们需要纪律和围栏。下面描述的 DevOps 思维模式的五个基本价值观将支持将我们的实践。这些价值观不是新观念;正如我们从经验中学到的那样,它们被重构了。一些价值观可以互换的,它们是灵活的,并且它们如支柱一样导向了支持这五个价值观的整体原则。

 title=

1、利益相关方的反馈至关重要

我们如何知道我们是否为我们创造了比利益相关方更多的价值?我们需要持久的质量数据来分析、通知并推动更好的决策。来自可靠来源的相关信息对于任何业务的蓬勃发展至关重要。我们需要倾听并理解我们的利益相关方所说的,而不是说我们需要以一种方式实施变革,使我们能够调整我们的思维、流程和技术,并根据需要对其进行调整以使我们的利益相关者满意。由于信息(数据)不正确,我们常常看到的变化过少,或者由于错误的原因而发生了很多变化。因此,将变更与利益相关方的反馈结合起来是一项基本价值观,并有助我们专注于使公司成功最重要的事情。

关注我们的利益相关方及其反馈,而不仅仅是为了改变而改变。

2、超越当今流程的极限进行改进

我们希望我们的产品和服务能够不断让客户满意,他们是我们最重要的利益相关方。因此,我们需要不断改进。这不仅仅是关系到质量;它还可能意味着成本、可用性、相关性以及许多其他目标和因素。创建可重复的流程或使用通用框架是非常棒的,它们可以改善治理和许多其他问题。但是,这不应该是我们的最终目标。在寻找改进方法时,我们必须调整我们的流程,并辅以正确的技术和工具。可能有理由抛出一个“所谓的”框架,因为不这样做可能会增加浪费,更糟糕的是只是“货物结果”(做一些没有价值或目的的东西)。

力争始终创新并改进可重复的流程和框架。

3、不要用新的孤岛来打破旧的孤岛

孤岛和 DevOps 是不兼容的。我们经常能看到:IT 主管带来了所谓的“专家”来实施敏捷和 DevOps,他们做了什么?这些“专家”在现有问题的基础上创建了一个新问题,这是 IT 部门和业务中又增加了一个孤岛。创造“DevOps”职位违背了敏捷和 DevOps 基于打破孤岛的原则。在敏捷和 DevOps 中,团队合作是必不可少的,如果你不在自组织团队中工作,那么你就不会做任何事情。

相互激励和共享,而不是成为英雄或创建一个孤岛。

4、了解你的客户意味着跨组织协作

企业的任何一个部分都不是一个独立的实体,因为它们都有利益相关方,主要利益相关方始终是客户。“客户永远是对的”(或国王,我喜欢这样说)。关键是,没有客户就真的没有业务,而且为了保持业务,如今我们需要与竞争对手“区别对待”。我们还需要了解客户对我们的看法以及他们对我们的期望。了解客户的需求势在必行,需要及时反馈,以确保业务能够快速、负责地满足这些主要利益相关者的需求和关注。

 title=

无论是想法、概念、假设还是直接利益相关方的反馈,我们都需要通过使用探索、构建、测试和交付生命周期来识别和衡量我们的产品提供的功能或服务。从根本上说,这意味着我们需要在整个组织中“插入”我们的组织。在持续创新、学习和 DevOps 方面没有任何边界。因此,当我们在整个企业中进行衡量时,我们可以理解整体并采取可行的、有意义的步骤来改进。

衡量整个组织的绩效,而不仅仅是在业务范围内。

5、通过热情鼓励采纳

不是每个人都要被驱使去学习、适应和改变;然而,就像微笑可能具有传染性一样,学习和意愿成为变革文化的一部分也是如此。在学习文化中适应和演化为一群人提供了学习和传递信息(即文化传播)的自然机制。学习风格、态度、方法和过程不断演化,因此我们可以改进它们。下一步是应用所学和改进的内容并与同事分享信息。学习不会自动发生;它需要努力、评估、纪律、意识,特别是沟通;遗憾的是,这些都是工具和自动化无法提供的。检查你的流程、自动化、工具策略和实施工作,使其透明化,并与你的同事协作重复使用和改进。

通过精益交付促进学习文化,而不仅仅是工具和自动化。

总结

 title=

随着我们的公司采用 DevOps,我们继续在各种书籍、网站或自动化软件上倡导这五个价值观。采用这种思维方式需要时间,这与我们以前作为系统管理员所做的完全不同。这是一种全新的工作方式,需要很多年才能成熟。这些原则是否与你自己的原则一致?在评论或我们的网站 Agents of chaos 上分享。


via: https://opensource.com/article/19/5/values-devops-mindset

作者:Brent Aaron Reed 选题:lujun9972 译者:arrowfeng 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出