这些开源的工具能够通过输出帮助用户了解系统的运行状况，并对可能发生的潜在问题作出告警。

你大概已经知道（或猜到）告警可视化alerting and visualization工具是用来做什么的了。下面我们就要来说一下，为什么要讨论这样的工具，甚至某些系统专门将可视化作为特有的功能。

可观察性Observability的概念来自控制理论control theory，这个概念描述了我们通过对系统的输入和输出来了解其的能力。本文将重点介绍具有可观察性的输出组件。

告警可视化工具可以对其它系统的输出进行分析，进而对输出的信息进行结构化表示。告警实际上是对系统异常状态的描述，而可视化则是让用户能够直观理解的结构化表示。

常见的可视化告警

告警

首先要明确一下告警alert的含义。在人员无法响应告警内容情况下，不应该发送告警 —— 包括那些发给多个人但只有其中少数人可以响应的告警，以及系统中的每个异常都触发的告警。因为这样会产生告警疲劳，告警接收者也往往会对这些过多的告警采取忽视的态度 —— 直到系统恶化到以少见的方式告警。

例如，如果管理员每天都会收到告警系统发来的数百封告警邮件，他就很容易会忽略告警系统的所有邮件。除非他真的看到问题发生，或者受到了客户或上级的询问时，管理员才会重新重视告警信息。在这种情况下，告警已经失去了原有的意义和用途。

告警不是一个持续的信息流或者状态更新。告警的目的在于暴露系统无法自动恢复的问题，而且告警应该只发送给最有可能解决问题的人员。超出这个定义的内容都不应该作为告警，否则将会对实际工作造成不良的影响。

不同的告警体系都会有各自的告警类型，因此不能用优先级（P1-P5）或者诸如“信息”、“警告”、“严重”之类的字眼来一概而论，下面我会介绍一些新兴的复杂系统的事件响应中出现的通用分类方式。

刚才我提到了一个“信息”这个告警类型，但实际上告警不应该是一个信息，尽管有些人可能会不这样认为。但我觉得如果一个告警没有发送给任何一个人，它就不应该是警报，而只是一些在许多系统中被视为警报的数据点，代表了一些应该知晓但不需要响应的事件。它更应该作为告警可视化工具的一部分，而不是会导致触发告警的事件。《实用监控》是这个领域的必读书籍，其作者 Mike Julian 在书中就介绍了他自己关于告警的看法。

而非信息警报则代表告警需要被响应以及需要相关的操作。我将这些告警大致分为内部故障和外部故障两种类型，而对于大多数公司来说，通常会有两个以上的级别来确定响应告警的优先级。系统性能下降就是一种故障，因为其对用户的影响通常都是未知的。

内部故障比外部故障的优先级低，但也需要快速响应。内部故障通常包括公司员工使用的内部系统或仅对公司员工可见的应用故障。

外部故障则包括任何马上会产生业务影响的系统故障，但不包括影响系统更新的故障。外部故障一般包括客户所面临的应用故障、数据库故障和导致系统可用性或一致性失效的网络故障，这些都会影响用户的正常使用。对于不直接影响用户的依赖组件故障也属于外部故障，随着应用程序的不断运行，一旦依赖组件发生故障，系统的性能也会受到波及。这种情况对于使用某些外部服务或数据源的系统来说很常见，尽管这些外部服务或数据源对于可能不涉及到系统的主要功能，但是当系统在处理相关依赖组件的错误时可能会出现较明显的延迟。

可视化

可视化的种类有很多，我就不一一赘述了。这是一个有趣的研究领域，在我这些年的数据分析经历当中，学习和应用可视化方面的知识可以说是相当有挑战性。我们需要将复杂的系统输出通过直观的方式来向他人展示，才能有效地把信息传播出去。Google Charts 和 Tableau 都提供了很多可视化方面的工具。下面将会介绍一些最常见的可视化创新解决方案。

折线图

折线图可能是最常见的可视化方式了，它可以让用户很直观地按照时间维度了解系统的情况。系统中每个单一或聚合的指标都会以一条折线在图表中体现。但当同一个图表中同时存在多条折线时，就可能会对阅读有所影响（如下图所示），所以大多数情况下都可以选择仅查看其中的少数几条折线，而不是让所有折线同时显示。如果某个指标的数值产生了大于正常范围的波动，就会很容易发现。例如下图中异常的紫线、黄线、浅蓝线。

折线图的另一个用法是可以将多条折线堆叠起来以显示它们之间的关系。例如对于通过折线图反映服务器的请求数量，可以单独看到每台服务器上的请求，也可以聚合在一起看。这就可以在同一个图表中灵活查看整个系统以及每个实例的情况了。

热力图

另一种常见的可视化方式是热力图。热力图与条形图比较类似，还可以在条形图的基础上显示某部分在整体中占比的变化情况。例如在查看网络请求延时的时候，就可以使用热力图快速查看到所有网络请求的总体趋势和分布情况，另外，它可以使用不同颜色来表示不同部分的数值。

在以下这个热力图中，通过竖直方向上每个时间段的色块数量分布，可以清楚地看到大部分数据集中在整个范围的中心位置。我们还可以发现，大多数时间段的色块分布都是比较宽松的，而 14:00 到 15:00 这一段则分布得很密集，这样的分布有可能意味着一种不健康的状态。

仪表图

还有一种常见的可视化方式是仪表图，用户可以通过仪表图快速了解单个指标。仪表一般用于单个指标的显示，例如车速表代表汽车的行驶速度、油量表代表油箱中的汽油量等等。大多数的仪表图都有一个共通点，就是会划分出所示指标的对应状态。如下图所示，绿色表示正常的状态，橙色表示不良的状态，而红色则表示极差的状态。下图中间一行模拟了真实仪表的显示情况。

上面图表中，除了常规仪表样式的显示方式之外，还有较为直接的数据显示方式，配合相同的配色方案，一眼就可以看出各个指标所处的状态，这一点与和仪表的特点类似。所以，最下面一行可能是仪表图的最佳显示方式，用户不需要仔细阅读，就可以大致了解各个指标的不同状态。这种类型的可视化是我最常用的类型，在数秒钟之间，我就可以全面地总览系统各方面地运行情况。

火焰图

由 Netflix 的 Brendan Gregg 在 2011 年开始使用的火焰图是一种较为少见地可视化方式。它不像仪表图那样可以从图表中快速得到关键信息，通常只会在需要解决某个应用的问题的时候才会用到这种图表。火焰图主要用于 CPU、内存和相关帧方面的表示，X 轴按字母顺序将帧一一列出，而 Y 轴则表示堆栈的深度。图中每个矩形都是一个标明了调用的函数的堆栈帧。矩形越宽，就表示它在堆栈中出现越频繁。在分析系统性能问题的时候，火焰图能够起到很大的作用，大家不妨尝试一下。

工具的选择

在告警工具方面，有几个商用的工具相当不错。但由于这是一篇介绍开源技术的文章，我只会介绍那些已经被广泛使用的免费工具。希望你也能够为这些工具贡献你自己的代码，让它们更加完善。

告警工具

Bosun

如果你的电脑出现问题，得多亏 Stack Exchange 你才能在网上查到解决办法。Stack Exchange 以众包问答的模式运营着很多不同类型的网站。其中就有广受开发者欢迎的 Stack Overflow，以及运维方面有名的 Super User。除此以外，从育儿经验到科幻小说、从哲学讨论到单车论坛，Stack Exchange 都有涉猎。

Stack Exchange 开源了它的告警管理系统 Bosun，同时也发布了 Prometheus 及其 AlertManager 系统。这两个系统有共通点。Bosun 和 Prometheus 一样使用 Golang 开发，但 Bosun 比 Prometheus 更为强大，因为它可以使用指标聚合metrics aggregation以外的方式与系统交互。Bosun 还可以从日志和事件收集系统中提取数据，并且支持 Graphite、InfluxDB、OpenTSDB 和 Elasticsearch。

Bosun 的架构包括一个单一的服务器的二进制文件，一个诸如 OpenTSDB 的后端、Redis 以及 scollector 代理。 scollector 代理会自动检测主机上正在运行的服务，并反馈这些进程和其它的系统资源的情况。这些数据将发送到后端。随后 Bosun 的二进制服务文件会向后端发起查询，确定是否需要触发告警。也可以通过 Grafana 这些工具通过一个通用接口查询 Bosun 的底层后端。而 Redis 则用于存储 Bosun 的状态信息和元数据。

Bosun 有一个非常巧妙的功能，就是可以根据历史数据来测试告警。这是我几年前在使用 Prometheus 的时候就非常需要的功能，当时我有一个异常的数据需要产生告警，但没有一个可以用于测试的简便方法。为了确保告警能够正常触发，我不得不造出对应的数据来进行测试。而 Bosun 让这个步骤的耗时大大缩短。

Bosun 更是涵盖了所有常用过的功能，包括简单的图形化表示和告警的创建。它还带有强大的用于编写告警规则的表达式语言。但 Bosun 默认只带有电子邮件通知配置和 HTTP 通知配置，因此如果需要连接到 Slack 或其它工具，就需要对配置作出更大程度的定制化（其文档中有）。类似于 Prometheus，Bosun 还可以使用模板通知，你可以使用 HTML 和 CSS 来创建你所需要的电子邮件通知。

Cabot

Cabot 由 Arachnys 公司开发。你或许对 Arachnys 公司并不了解，但它很有影响力：Arachnys 公司构建了一个基于云的先进解决方案，用于防范金融犯罪。在之前的公司时，我也曾经参与过类似“了解你的客户（KYC）”的工作。大多数公司都认为与恐怖组织产生联系会造成相当不好的影响，因为恐怖组织可能会利用自己的系统来筹集资金。而这些解决方案将有助于防范欺诈类犯罪，尽管这类犯罪情节相对较轻，但仍然也会对机构产生风险。

Arachnys 公司为什么要开发 Cabot 呢？其实只是因为 Arachnys 的开发人员对 Nagios 不太熟悉。Cabot 的出现对很多人来说都是一个好消息，它基于 Django 和 Bootstrap 开发，因此如果想对这个项目做出自己的贡献，门槛并不高。（另外值得一提的是，Cabot 这个名字来源于开发者的狗。）

与 Bosun 类似，Cabot 也不对数据进行收集，而是使用监控对象的 API 提供的数据。因此，Cabot 告警的模式是拉取而不是推送。它通过访问每个监控对象的 API，根据特定的指标检索所需的数据，然后将告警数据使用 Redis 缓存，进而持久化存储到 Postgres 数据库。

Cabot 的一个较为少见的特点是，它原生支持 Graphite，同时也支持 Jenkins。Jenkins 在这里被视为一个集中式的定时任务，它会以对待故障的方式去对待构建失败的状况。构建失败当然没有系统故障那么紧急，但一旦出现构建失败，还是需要团队采取措施去处理，毕竟并不是每个人在收到构建失败的电子邮件时都会亲自去检查 Jenkins。

Cabot 另一个有趣的功能是它可以接入 Google 日历安排值班人员，这个称为 Rota 的功能用处很大，希望其它告警系统也能加入类似的功能。Cabot 目前仅支持安排主备联系人，但还有继续改进的空间。它自己的文档也提到，如果需要全面的功能，更应该考虑付费的解决方案。

StatsAgg

Pearson 作为一家开发了 StatsAgg 告警平台的出版公司，这是极为罕见的，当然也很值得敬佩。除此以外，Pearson 还运营着另外几个网站以及和 O’Reilly Media 合资的企业。但我仍然会将它视为出版教学书籍的公司。

StatsAgg 除了是一个告警平台，还是一个指标聚合平台，甚至也有点类似其它系统的代理。StatsAgg 支持通过 Graphite、StatsD、InfluxDB 和 OpenTSDB 输入数据，也支持将其转发到各种平台。但随着中心服务的负载不断增加，风险也不断增大。尽管如此，如果 StatsAgg 的基础架构足够强壮，即使后端存储平台出现故障，也不会对它产生告警的过程造成影响。

StatsAgg 是用 Java 开发的，为了尽可能降低复杂性，它仅包括主服务和一个 UI。StatsAgg 支持基于正则表达式匹配来发送告警，而且它更注重于服务方面的告警，而不是服务器基础告警。我认为它填补了开源监控工具方面的空白，而这正式它自己的目标。

可视化工具

Grafana

Grafana 的知名度很高，它也被广泛采用。每当我需要用到数据面板的时候，我总是会想到它，因为它比我使用过的任何一款类似的产品都要好。Grafana 由 Torkel Ödegaard 开发的，像 Cabot 一样，也是在圣诞节期间开发的，并在 2014 年 1 月发布。在短短几年之间，它已经有了长足的发展。Grafana 基于 Kibana 开发，Torkel 开启了新的分支并将其命名为 Grafana。

Grafana 着重体现了实用性以及数据呈现的美观性。它天生就可以从 Graphite、Elasticsearch、OpenTSDB、Prometheus 和 InfluxDB 收集数据。此外有一个 Grafana 商用版插件可以从更多数据源获取数据，但是其他数据源插件也并非没有开源版本，Grafana 的插件生态系统已经提供了各种数据源。

Grafana 能做什么呢？Grafana 提供了一个中心化的了解系统的方式。它通过 web 来展示数据，任何人都有机会访问到相关信息，当然也可以使用身份验证来对访问进行限制。Grafana 使用各种可视化方式来提供对系统一目了然的了解。Grafana 还支持不同类型的可视化方式，包括集成告警可视化的功能。

现在你可以更直观地设置告警了。通过 Grafana，可以查看图表，还可以查看由于系统性能下降而触发告警的位置，单击要触发报警的位置，并告诉 Grafana 将告警发送何处。这是一个对告警平台非常强大的补充。告警平台不一定会因此而被取代，但告警系统一定会由此得到更多启发和发展。

Grafana 还引入了很多团队协作的功能。不同用户之间能够共享数据面板，你不再需要为 Kubernetes 集群创建独立的数据面板，因为由 Kubernetes 开发者和 Grafana 开发者共同维护的一些数据面板已经可用了。

团队协作过程中一个重要的功能是注释。注释功能允许用户将上下文添加到图表当中，其他用户就可以通过上下文更直观地理解图表。当团队成员在处理某个事件，并且需要沟通和理解时，这个功能就十分重要了。将所有相关信息都放在需要的位置，可以让整个团队中快速达成共识。在团队需要调查故障原因和定位事件责任时，这个功能就可以发挥作用了。

Vizceral

Vizceral 由 Netflix 开发，用于在故障发生时更有效地了解流量的情况。Grafana 是一种通用性更强的工具，而 Vizceral 则专用于某些领域。 尽管 Netflix 表示已经不再在内部使用 Vizceral，也不再主动对其展开维护，但 Vizceral 仍然会定期更新。我在这里介绍这个工具，主要是为了介绍它的的可视化机制，以及如何利用它来协助解决问题。你可以在样例环境中用它来更好地掌握这一类系统的特性。

via: https://opensource.com/article/18/10/alerting-and-visualization-tools-sysadmins

管道命令的作用是将一个命令/程序/进程的输出发送给另一个命令/程序/进程，以便将输出结果进行进一步的处理。我们可以通过使用管道命令把多个命令组合起来，使一个命令的标准输入或输出重定向到另一个命令。两个或多个 Linux 命令之间的竖线字符（|）表示在命令之间使用管道命令。管道命令的一般语法如下所示：

1

Command-1 | Command-2 | Command-3 | …| Command-N

Ultimate Plumber（简称 UP）是一个命令行工具，它可以用于即时预览管道命令结果。如果你在使用 Linux 时经常会用到管道命令，就可以通过它更好地运用管道命令了。它可以预先显示执行管道命令后的结果，而且是即时滚动地显示，让你可以轻松构建复杂的管道。

下文将会介绍如何安装 UP 并用它将复杂管道命令的编写变得简单。

重要警告：

在生产环境中请谨慎使用 UP！在使用它的过程中，有可能会在无意中删除重要数据，尤其是搭配 rm 或 dd 命令时需要更加小心。勿谓言之不预。

使用 Ultimate Plumber 即时预览管道命令

下面给出一个简单的例子介绍 up 的使用方法。如果需要将 lshw 命令的输出传递给 up，只需要在终端中输入以下命令，然后回车：

1

$ lshw |& up

你会在屏幕顶部看到一个输入框，如下图所示。

在输入命令的过程中，输入管道符号并回车，就可以立即执行已经输入了的命令。Ultimate Plumber 会在下方的可滚动窗口中即时显示管道命令的输出。在这种状态下，你可以通过 PgUp/PgDn 键或 ctrl + ←/ctrl + → 组合键来查看结果。

当你满意执行结果之后，可以使用 ctrl + x 组合键退出 UP。而退出前编写的管道命令则会保存在当前工作目录的文件中，并命名为 up1.sh。如果这个文件名已经被占用，就会命名为 up2.sh、up3.sh 等等以此类推，直到第 1000 个文件。如果你不需要将管道命令保存输出，只需要使用 ctrl + c 组合键退出即可。

通过 cat 命令可以查看 upX.sh 文件的内容。例如以下是我的 up2.sh 文件的输出内容：

1
2
3

$ cat up2.sh
#!/bin/bash
grep network -A5 | grep : | cut -d: -f2- | paste - -

如果通过管道发送到 up 的命令运行时间太长，终端窗口的左上角会显示一个波浪号（~）字符，这就表示 up 在等待前一个命令的输出结果作为输入。在这种情况下，你可能需要使用 ctrl + s 组合键暂时冻结 up 的输入缓冲区大小。在需要解冻的时候，使用 ctrl + q 组合键即可。Ultimate Plumber 的输入缓冲区大小一般为 40 MB，到达这个限制之后，屏幕的左上角会显示一个加号。

以下是 up 命令的一个简单演示：

安装 Ultimate Plumber

喜欢这个工具的话，你可以在你的 Linux 系统上安装使用。安装过程也相当简单，只需要在终端里执行以下两个命令就可以安装 up 了。

首先从 Ultimate Plumber 的发布页面下载最新的二进制文件，并将放在你系统的某个路径下，例如 /usr/local/bin/。

1

$ sudo wget -O /usr/local/bin/up wget https://github.com/akavel/up/releases/download/v0.2.1/up

然后向 up 二进制文件赋予可执行权限：

1

$ sudo chmod a+x /usr/local/bin/up

至此，你已经完成了 up 的安装，可以开始编写你的管道命令了。

via: https://www.ostechnix.com/ultimate-plumber-writing-linux-pipes-with-instant-live-preview/

尝试使用 Python 掌握机器学习、人工智能和深度学习。

想要入门机器学习并不难。除了大规模网络公开课Massive Open Online Courses（MOOC）之外，还有很多其它优秀的免费资源。下面我分享一些我觉得比较有用的方法。

1. 从一些 YouTube 上的好视频开始，阅览一些关于这方面的文章或者书籍，例如 《主算法：终极学习机器的探索将如何重塑我们的世界》，而且我觉得你肯定会喜欢这些关于机器学习的很酷的互动页面。
2. 对于“机器学习machine learning”、“人工智能artificial intelligence”、“深度学习deep learning”、“数据科学data science”、“计算机视觉computer vision”和“机器人技术robotics”这一堆新名词，你需要知道它们之间的区别。你可以阅览或聆听这些领域的专家们的演讲，例如这位有影响力的数据科学家 Brandon Rohrer 的精彩视频。或者这个讲述了数据科学相关的各种角色之间的区别的视频。
3. 明确你自己的学习目标，并选择合适的 Coursera 课程，或者参加高校的网络公开课，例如华盛顿大学的课程就很不错。
4. 关注优秀的博客：例如 KDnuggets 的博客、Mark Meloon 的博客、Brandon Rohrer 的博客、Open AI 的研究博客，这些都值得推荐。
5. 如果你热衷于在线课程，后文中会有如何正确选择 MOOC 课程的指导。
6. 最重要的是，培养自己对这些技术的兴趣。加入一些优秀的社交论坛，不要被那些耸人听闻的头条和新闻所吸引，专注于阅读和了解，将这些技术的背景知识和发展方向理解透彻，并积极思考在日常生活和工作中如何应用机器学习或数据科学的原理。例如建立一个简单的回归模型来预测下一次午餐的成本，又或者是从电力公司的网站上下载历史电费数据，在 Excel 中进行简单的时序分析以发现某种规律。在你对这些技术产生了浓厚兴趣之后，可以观看以下这个视频。

https://www.youtube.com/embed/IpGxLWOIZy4

Python 是机器学习和人工智能方面的最佳语言吗？

除非你是一名专业的研究一些复杂算法纯理论证明的研究人员，否则，对于一个机器学习的入门者来说，需要熟悉至少一种高级编程语言。因为大多数情况下都是需要考虑如何将现有的机器学习算法应用于解决实际问题，而这需要有一定的编程能力作为基础。

哪一种语言是数据科学的最佳语言？这个讨论一直没有停息过。对于这方面，你可以提起精神来看一下 FreeCodeCamp 上这一篇关于数据科学语言的文章，又或者是 KDnuggets 关于 Python 和 R 之争的深入探讨。

目前人们普遍认为 Python 在开发、部署、维护各方面的效率都是比较高的。与 Java、C 和 C++ 这些较为传统的语言相比，Python 的语法更为简单和高级。而且 Python 拥有活跃的社区群体、广泛的开源文化、数百个专用于机器学习的优质代码库，以及来自业界巨头（包括 Google、Dropbox、Airbnb 等）的强大技术支持。

基础 Python 库

如果你打算使用 Python 实施机器学习，你必须掌握一些 Python 包和库的使用方法。

NumPy

NumPy 的完整名称是 Numerical Python，它是 Python 生态里高性能科学计算和数据分析都需要用到的基础包，几乎所有高级工具（例如 Pandas 和 scikit-learn）都依赖于它。TensorFlow 使用了 NumPy 数组作为基础构建块以支持 Tensor 对象和深度学习的图形流。很多 NumPy 操作的速度都非常快，因为它们都是通过 C 实现的。高性能对于数据科学和现代机器学习来说是一个非常宝贵的优势。

Pandas

Pandas 是 Python 生态中用于进行通用数据分析的最受欢迎的库。Pandas 基于 NumPy 数组构建，在保证了可观的执行速度的同时，还提供了许多数据工程方面的功能，包括：

• 对多种不同数据格式的读写操作
• 选择数据子集
• 跨行列计算
• 查找并补充缺失的数据
• 将操作应用于数据中的独立分组
• 按照多种格式转换数据
• 组合多个数据集
• 高级时间序列功能
• 通过 Matplotlib 和 Seaborn 进行可视化

Matplotlib 和 Seaborn

数据可视化和数据分析是数据科学家的必备技能，毕竟仅凭一堆枯燥的数据是无法有效地将背后蕴含的信息向受众传达的。这两项技能对于机器学习来说同样重要，因为首先要对数据集进行一个探索性分析，才能更准确地选择合适的机器学习算法。

Matplotlib 是应用最广泛的 2D Python 可视化库。它包含海量的命令和接口，可以让你根据数据生成高质量的图表。要学习使用 Matplotlib，可以参考这篇详尽的文章。

Seaborn 也是一个强大的用于统计和绘图的可视化库。它在 Matplotlib 的基础上提供样式灵活的 API、用于统计和绘图的常见高级函数，还可以和 Pandas 提供的功能相结合。要学习使用 Seaborn，可以参考这篇优秀的教程。

Scikit-learn

Scikit-learn 是机器学习方面通用的重要 Python 包。它实现了多种分类、回归和聚类算法，包括支持向量机、随机森林、梯度增强、k-means 算法和 DBSCAN 算法，可以与 Python 的数值库 NumPy 和科学计算库 SciPy 结合使用。它通过兼容的接口提供了有监督和无监督的学习算法。Scikit-learn 的强壮性让它可以稳定运行在生产环境中，同时它在易用性、代码质量、团队协作、文档和性能等各个方面都有良好的表现。可以参考这篇基于 Scikit-learn 的机器学习入门，或者这篇基于 Scikit-learn 的简单机器学习用例演示。

本文使用 CC BY-SA 4.0 许可，在 Heartbeat 上首发。

via: https://opensource.com/article/18/10/machine-learning-python-essential-hacks-and-tricks

推动大规模的组织变革是一个痛苦的过程。对于 DevOps 来说，尽管也有阵痛，但变革带来的价值则相当可观。

避免痛苦是一种强大的动力。一些研究表明，植物也会通过遭受疼痛的过程以采取措施来保护自己。我们人类有时也会刻意让自己受苦——在剧烈运动之后，身体可能会发生酸痛，但我们仍然坚持运动。那是因为当人认为整个过程利大于弊时，几乎可以忍受任何事情。

推动大规模的组织变革的过程确实是痛苦的。有人可能会因难以改变价值观和行为而感到痛苦，有人可能会因难以带领团队而感到痛苦，也有人可能会因难以开展工作而感到痛苦。但就 DevOps 而言，我可以说这些痛苦都是值得的。

我也曾经关注过一个团队耗费大量时间优化技术流程的过程，在这个过程中，团队逐渐将流程进行自动化改造，并最终获得了成功。

图片来源：Lee Eason. CC BY-SA 4.0

这张图表充分表明了变革的价值。一家公司在我主导实行了 DevOps 转型之后，60 多个团队每月提交了超过 900 个发布请求。这些工作量的原耗时高达每个月 350 人/天，而这么多的工作量对于任何公司来说都是不可忽视的。除此以外，他们每月的部署次数从 100 次增加到了 9000 次，高危 bug 减少了 24%，工程师们更轻松了，净推荐值Net Promoter Score（NPS）也提高了，而 NPS 提高反过来也让团队的 DevOps 转型更加顺利。正如 Puppet 发布的 DevOps 报告所预测的，用在技术流程改进上的投入可以在业务成果上明显地体现出来。

而 DevOps 主导者在推动变革时必须关注这三个方面：团队管理，团队文化和团队活力。

团队管理

最重要的是，改进对技术流程的投入可以转化为更好的业务成果。

组织架构越大，业务领导与一线员工之间的距离就会越大，当然发生误解的可能性也会越大。而且各种技术工具和实际应用都在以日新月异的速度变化，这就导致业务领导几乎不可能对 DevOps 或敏捷开发的转型方向有一个亲身的了解。

DevOps 主导者必须和管理层密切合作，在进行决策的时候给出相关的意见，以帮助他们做出正确的决策。

公司的管理层只是知道 DevOps 会对产品部署的方式进行改进，而并不了解其中的具体过程。假设你正在帮助一个软件开发团队实现自动化部署，当管理层得知某次部署失败时（这种情况是有的），就会想要了解这件事情的细节。如果管理层了解到进行部署的是软件团队而不是专门的发布管理团队，就可能会坚持使用传统的变更流程来保证业务的正常运作。你可能会失去团队的信任，团队也可能不愿意做出进一步的改变。

如果没有和管理层做好心理上的预期，一旦发生意外的生产事件，重建管理层的信任并得到他们的支持比事先对他们进行教育需要更长的时间。所以，最好事先和管理层在各方面协调好，这会让你在后续的工作中避免很多麻烦。

对于和管理层之间的协调，这里有两条建议：

• 一是重视所有规章制度。如果管理层对合同、安全等各方面有任何疑问，你都可以向法务或安全负责人咨询，这样做可以避免犯下后果严重的错误。
• 二是将管理层重点关注的方面输出为量化指标。举个例子，如果公司的目标是减少客户流失，而你调查得出计划外的服务宕机是造成客户流失的主要原因，那么就可以让团队对故障的平均排查时间Mean Time To Detection（MTTD）和平均解决时间Mean Time To Resolution（MTTR）实行重点优化。你可以使用这些关键指标来量化团队的工作成果，而管理层对此也可以有一个直观的了解。

团队文化

DevOps 是一种专注于持续改进代码、构建、部署和操作流程的文化，而团队文化代表了团队的价值观和行为。从本质上说，团队文化是要塑造团队成员的行为方式，而这并不是一件容易的事。

我推荐一本叫做《披着狼皮的 CIO》的书。另外，研究心理学、阅读《Drive》、观看 Daniel Pink 的 TED 演讲、阅读《千面英雄》、了解每个人的心路历程，以上这些都是你推动公司技术变革所应该尝试去做的事情。如果这些你都没兴趣，说明你不是那个推动公司变革的人。如果你想成为那个人，那就开始学习吧！

从本质上说，改变一个人真不是件容易的事。

理性的人大多都按照自己的价值观工作，然而团队通常没有让每个人都能达成共识的明确价值观。因此，你需要明确团队目前的价值观，包括价值观的形成过程和价值观的目标导向。但不能将这些价值观强加到团队成员身上，只需要让团队成员在现有条件下力所能及地做到最好就可以了。

同时需要向团队成员阐明，公司正在发生组织和团队目标的变化，团队的价值观也随之改变，最好也厘清整个过程中将会作出什么变化。例如，公司以往或许是由于资金有限，一直将节约成本的原则放在首位，在研发新产品的时候，基础架构团队不得不共享数据库集群或服务器，从而导致了服务之间的紧密耦合。然而随着时间的推移，这种做法会产生难以维护的混乱，即使是一个小小的变化也可能造成无法预料的后果。这就导致交付团队难以执行变更控制流程，进而令变更停滞不前。

如果这种状况持续几年，最终的结果将会是毫无创新、技术老旧、问题繁多以及产品品质低下，公司的发展到达了瓶颈，原本的价值观已经不再适用。所以，工作效率的优先级必须高于节约成本。如果一个选择能让团队运作更好，另一个选择只是短期来看成本便宜，那你应该选择前者。

你必须反复强调团队的价值观。每当团队取得了一定的工作进展（即使探索创新时出现一些小的失误），都应该对团队作出激励。在团队部署出现失败时，鼓励他们承担风险、吸取教训，同时指导团队如何改进他们的工作并表示支持。长此下来，团队成员就会对你产生信任，不再顾虑为切合团队的价值观而做出改变。

团队活力

你有没有在会议上听过类似这样的话？“在张三度假回来之前，我们无法对这件事情做出评估。他是唯一一个了解代码的人”，或者是“我们完成不了这项任务，它在网络上需要跨团队合作，而防火墙管理员刚好请病假了”，又或者是“张三最清楚这个系统，他说是怎么样，通常就是怎么样”。那么如果团队在处理工作时，谁才是主力？就是张三。而且也一直会是他。

我们一直都认为这就是软件开发的自带属性。但是如果我们不作出改变，这种循环就会一直持续下去。

熵的存在会让团队自发地变得混乱和缺乏活力，团队的成员和主导者的都有责任控制这个熵并保持团队的活力。DevOps、敏捷开发、上云、代码重构这些行为都会令熵加速增长，这是因为转型让团队需要学习更多新技能和专业知识以开展新工作。

我们来看一个产品团队重构历史代码的例子。像往常一样，他们在 AWS 上构建新的服务。而传统的系统则在数据中心部署，并由 IT 部门进行监控和备份。IT 部门会确保在基础架构的层面上满足应用的安全需求、进行灾难恢复测试、系统补丁、安装配置了入侵检测和防病毒代理，而且 IT 部门还保留了年度审计流程所需的变更控制记录。

产品团队经常会犯一个致命的错误，就是认为 IT 是消耗资源的部门，是需要突破的瓶颈。他们希望脱离已有的 IT 部门并使用公有云，但实际上是他们忽视了 IT 部门提供的关键服务。迁移到云上只是以不同的方式实现这些关键服务，因为 AWS 也是一个数据中心，团队即使使用 AWS 也需要完成 IT 运维任务。

实际上，产品团队在向云迁移的时候也必须学习如何使用这些 IT 服务。因此，当产品团队开始重构历史代码并部署到云上时，也需要学习大量的技能才能正常运作。这些技能不会无师自通，必须自行学习或者聘用相关的人员，团队的主导者也必须积极进行管理。

在带领团队时，我找不到任何适合我的工具，因此我建立了 Tekita.io 这个项目。Tekata 免费而且容易使用。但相比起来，把注意力集中在人员和流程上更为重要，你需要不断学习，持续关注团队的短板，因为它们会影响团队的交付能力，而弥补这些短板往往需要学习大量的新知识，这就需要团队成员之间有一个很好的协作。因此 76％ 的年轻人都认为个人发展机会是公司文化最重要的的一环。

效果就是最好的证明

DevOps 转型会改变团队的工作方式和文化，这需要得到管理层的支持和理解。同时，工作方式的改变意味着新技术的引入，所以在管理上也必须谨慎。但转型的最终结果是团队变得更高效、成员变得更积极、产品变得更优质，客户也变得更满意。

Lee Eason 将于 10 月 21-23 日在北卡罗来纳州 Raleigh 举行的 All Things Open 上讲述 DevOps 转型的故事。

免责声明：本文中的内容仅为 Lee Eason 的个人立场，不代表 Ipreo 或 IHS Markit。

via: https://opensource.com/article/18/10/tales-devops-transformation

并非所有 web 浏览器都要做到无所不能，Min 就是一个极简主义风格的浏览器。

现在还有开发新的 Web 浏览器的需要吗？即使现在浏览器领域已经成为了寡头市场，但仍然不断涌现出各种前所未有的浏览器产品。

Min 就是其中一个。顾名思义，Min 是一个小的浏览器，也是一个极简主义的浏览器。但它麻雀虽小五脏俱全，而且还是一个开源的浏览器，它的 Apache 2.0 许可证引起了我的注意。

让我们来看看 Min 有什么值得关注的方面。

开始

Min 基于 Electron 框架开发，值得一提的是，Atom 文本编辑器也是基于这个框架开发的。它提供 Linux、MacOS 和 Windows 的安装程序，当然也可以从 GitHub 获取它的源代码自行编译安装。

我使用的 Linux 发行版是 Manjaro，但没有完全匹配这个发行版的安装程序。还好，我通过 Manjaro 的包管理器也能安装 Min。

安装完成后，在终端就可以直接启动 Min。

Min 号称是更智能、更快速的浏览器。经过尝试以后，我觉得它比我在其它电脑上使用过的 Firefox 和 Chrome 浏览器启动得更快。

而使用 Min 浏览网页的过程则和 Firefox 或 Chrome 一样，只要再地址栏输入 URL，回车，就好了。

Min 的功能

尽管 Min 不可能带有 Firefox 或 Chrome 等浏览器得所有功能，但它也有可取之处。

Min 和其它浏览器一样，支持页面选项卡。它还有一个称为 Tasks 的功能，可以对打开的选项卡进行分组。

DuckDuckGo 是我最喜欢的搜索引擎，而 Min 的默认搜索引擎恰好就是它，这正合我意。当然，如果你喜欢另一个搜索引擎，也可以在 Min 的偏好设置中配置你喜欢的搜索引擎作为默认搜索引擎。

Min 没有使用类似 AdBlock 这样的插件来过滤你不想看到的内容，而是使用了一个名为 EasyList 的内置的广告拦截器，你可以使用它来屏蔽脚本和图片。另外 Min 还带有一个内置的防跟踪软件。

类似 Firefox，Min 有一个名为叫做 Reading List 的阅读模式。只需点击地址栏中的对应图标，就可以去除页面中的大部分无关内容，让你专注于正在阅读的内容。网页在阅读列表中可以保留 30 天。

Min 还有一个专注模式，可以隐藏其它选项卡并阻止你打开新的选项卡。在专注模式下，如果一个 web 页面中进行工作，需要多点击好几次才能打开一个新页面。

Min 也有很多快捷键让你快速使用某个功能。你可以在 GitHub 上找到这些这些快捷键的参考文档，也可以在 Min 的偏好设置中进行更改。

我发现 Min 可以在 YouTube、Vimeo、Dailymotion 等视频网站上播放视频，还可以在音乐网站 7Digital 上播放音乐。但由于我没有账号，所以没法测试是否能在 Spotify 或 Last.fm 等这些网站上播放音乐。

Min 的弱点

Min 确实也有自己的缺点，例如它无法将网站添加为书签。替代方案要么是查看 Min 的搜索历史来找回你需要的链接，要么是使用一个第三方的书签服务。

最大的缺点是 Min 不支持插件。这对我来说不是一件坏事，因为浏览器启动速度和运行速度快的主要原因就在于此。当然也有一些人非常喜欢使用浏览器插件，Min 就不是他们的选择。

总结

Min 算是一个中规中矩的浏览器，它可以凭借轻量、快速的优点吸引很多极简主义的用户。但是对于追求多功能的用户来说，Min 就显得相当捉襟见肘了。

所以，如果你想摆脱当今多功能浏览器的束缚，我觉得可以试用一下 Min。

via: https://opensource.com/article/18/10/min-web-browser