在回答“如何衡量成功？”之前，您需要了解“成功”对您而言意味着什么。 对于Dev和Ops，成功的定义是不同的。 对于开发人员，成功的项目已经过全面测试。 用于操作-监视。 测试和监视是必要的，但是测试永远不能100％覆盖问题，并且HTTP响应200不足以确保系统正常运行。 RIT ++的 Leon Fayer辩称，DevOps不会为确保监视中的所有指标都位于绿色区域而付出代价。 他们付出使用户满意 。 如果您不满意-企业正在亏本，而且没人在乎一切都是绿色的。
在猫之下，有许多实践证明了这一观点的例子。 让我们弄清楚为什么要了解业务，如何从业务角度监控成功以及普通开发人员为什么需要它。
关于演讲者：莱昂·费耶（Leon Fayer）出生于曾经友好的共和国，但在美国长大。 我是在多年前开始编程的，在那段时间里，我曾是一名程序员，经理，但我只是没有工作过。 参加了创业公司-有些更成功，有些不是很成功。
Leon多年来一直在OmniTI工作。 该公司专门从事可伸缩系统的开发，因此Leon拥有独特的机会来设计和构建世界上访问量最大的站点的系统-维基百科，国家地理，白宫，MTV等。
在回答“如何衡量成功？”问题之前，您需要了解“成功”对您而言意味着什么。 对于每个人，答案都会有所不同。
如果您正在阅读本文，则最有可能参与DevOps。 您比操作员还多吗？ 或者相反，运维比开发更多？ 对于Dev和Ops，成功的定义有些不同：对于Dev，当然是测试。
测试中
对我而言，作为一名程序员，成功的测试意味着一切都井井有条，一切正常，一切正常-您可以在生产环境中运行它。 问题是我也是一个愤世嫉俗的人，而不是这样的测试爱好者 。 不是因为这很困难，也不是因为它很长-而是因为测试无法满足我的需求。
正确理解我的观点， 测试是一个强制性的过程 ，它应该包含在任何项目中，但是显然这不足以保证成功 。
有许多不同的测试选项：
您使用几种测试方法-1，2，3，5？ 而且，您没有在夜间警醒时醒来吗？ 一切都在生产中起作用吗？
问题在于测试给人以成功的幻想 。 这是预先确定的：我们知道火车必须离开A点到达B点，为此我们正在测试。 我们正在考虑一些选择。 如果火车从车轮上掉下来或用完了木头，这也就不足为奇了。 但是我们不测试例如火车抢劫。 我们无法对此进行测试，因为我们不知道这样的选择是否可行。
由于存在一些问题，因此测试根本不够。 当然，第一个是数据问题 。 任务在本地运行，但由于某种原因在生产中不起作用，这是一个标准问题。
无论我们如何努力。 不管我们进行多少次复制都没关系-开发和生产永远不会相等。 数据库中是否会有另一行，是否会有其他额外的请求-生产中总会有一些我们没想到的东西。
Wolfe + 585-世界上最长的姓氏：
休伯特·布莱恩
Wolfeschlegelsteinhausenbergerdorffwelchevoralternwaren-gewissenhaftschaferswessenschafewarenwohlgepflegeundsorgfaltigkeitbeschutzen-vorangreifendurchihrraubgierigfeindewelchevoralternzwolfhunderttausendjahres-vorandieerscheinenvonderersteerdemenschderraumschiffgenachtmittungsteinund- siebeniridiumelektrischmotorsgebrauchlichtalsseinursprungvonkraftgestartsein-langefahrthinzwischensternartigraumaufdersuchennachbarschaftdersternwelchege-habtbewohnbarplanetenkreisedrehensichundwohinderneuerassevonverstandig-menschlichkeitkonntefortpflanzenundsicherfreuenanlebenslanglichfreudeundruhe-mitnichteinfurchtvorangreifenvorandererintelligentgeschopfsvonhinzwischensternartigraum，
高级
如果有人在表单上输入这样的姓氏，那么很少有系统能够生存。 我知道整个系统至少可以飞行5个不同的点。
因此，第二个问题是用户的问题 。
这些人真有趣，他们会破坏一切。 老实说，如果没有用户，一切都会变得容易得多。
即使您的UI中只有一个按钮，他们仍然会找到一种打破我们正在做的事情的方法。
最好的例子是《魔兽世界》 。
对于不认识的人来说，这是一个由1000万人玩的在线游戏。 一次有相当传奇的错误。 腐败的血虫是用户如何破坏一切的完美示例。
与任何玩具一样，在魔兽世界中，新内容，新观念，新老板不断出现。 新上任的一位老板诅咒了该集团40名球员中的一位。 诅咒的原理就像一颗定时炸弹，它慢慢夺走了周围所有人的生命。 也就是说，有必要逃到一边-有一个整体的机制。 一切都很好，直到某个玩家决定在战斗中转移到这座城市...
这座城市有成千上万的各个阶层的人，也有最小的人。 不仅如此，还有一些非玩家角色也被诅咒所感染。 白天，服务器是空的。 不可能有任何其他玩家去任何地方。 从最真实的意义上讲，这成为一场游戏瘟疫。 我必须对所有服务器进行一次全面重启，才能消除诅咒并更改机制。 都是因为有一位测试员-我什至不知道该怎么称呼。
第三个主要问题是外部依赖性问题 。 我们都碰到了这一点：您所依赖的API突然停止工作； 或您停止控制API。
但这有一个更大的问题。 外部依赖性不仅可以是直接的，而且可以是间接的。 我们现在都使用OpenSource。 每个OpenSource产品都依赖于某些库，这些库也是OpenSource，并且受到其他人的支持。 发生故障时，它不仅会在此小模块中中断，还会在所有依赖此模块的中断中中断。
也许最理想的例子是大约一年前的最近-这是左脚 垫 。 这是node.js上的一个npm模块，它在字符串之前（在行的开头）显示空格。 我们不会讨论为什么制作此模块。 但是事实证明，它包含在许多流行的模块中。 在某个时候，作者认为他已经足够了，从npm中删除了此模块，并用node.js编写的代码的70％消失了。
如果您认为这是一个孤立的案例，那就错了。
还有一个is-odd模块，现在在npm中。 此模块定义是否为偶数。
我们不会讨论300万人不知道如何检查奇偶性的事实。 但是还有12个模块可以使用它！ 尚不知道这些模块中有多少仍在使用这些模块。 如果您觉得没有什么可以改变的-有5个版本！
回到我们的绵羊-还有更多选择：
- 目光短浅 -我们不知道将来会发生什么。 Y2K是一个很好的例子。 没有人只是想到2000年用Kobol编写的所有东西都会实现。
- 测试选项的数量 。
魔兽世界再次有一个很好的例子-他们在这个问题上有很多很好的例子。
游戏发行六个月后，人们开始呼吁某些玩家无法进入一个洞穴。 事实证明，只有种族和性别的一种版本无法进入这个洞穴-这些是雌性牛头人。
为什么要花6个月才能发现这个错误-毕竟有数百万人在玩游戏？ 因为牛头人是虚构的种族，是人与牛的混合物。 牛头人女人是一头会说话的牛。 没有人想玩牛，所以六个月来，没有一个人达到最高水平进入洞穴并发现这个虫子。 因此，没有人对其进行测试。
无论如何，很少有测试。 但是测试不能提供100％的覆盖率。 因此，测试不能保证成功。 这逐渐将我们带到第二部分-运营。 对于剥削，成功在于监督 。
监控方式
需要监视的原因有很多：
- 完美的代码不存在；
- 系统变得越来越复杂；
- 日益增长的外部依赖性；
- 期待->反应；
- ...
需要监视，因为一切都在变化。 这是主要原因。 而且，它在生产中，那里的一切都在不断变化，我们需要检测到这一点。
监控应涵盖哪些内容？ -就这样！ 这是一个简短的答案，但应涵盖所有内容。
这有点抽象。 实际上，我们都有一个要监控的清单：
- 基础设施
- 资料库
- 应用领域
- 整合点；
- 要求处理时间；
- 负载
- ...
可能有一百万个东西。 许多人在其系统上收集成千上万的度量标准。
我们将为此收集很多指标：
当然，我有点夸张，但是从Ops的角度来看，我们需要的是HTTP返回200 。 这意味着该站点一切正常。 网站一旦运作，就意味着数据库运作，应用程序运作-一切都井井有条。 从Ops的角度来看，成功的确切原因在于：所有图形都在绿色区域中，一切都正常工作-一切都很好！
每个人都知道Twitter是什么。 他们每天处理5亿条推文，这是一个疯狂的数字。
但是他们也以错误而著称。 错误的复杂性或难易程度具有传奇色彩，应从哪方面着手。
他们犯了一个错误：网站正在运行，客户可以编写推文，单击按钮，他们说谢谢，推文已发送-就是这样！ 他没有出现在任何地方，只是消失了，监视显示一切都井井有条。 该网站返回200请求-API正常工作。 但是没有鸣叫！
我有一位客户的最爱报价。 我在三个屏幕上修复了一个小时的问题，他大吼大叫为什么什么都不起作用。 当我试图解释正在解决的问题时，一个用两根手指打字并且不懂如何使用计算机的人告诉我：
“只要我继续赚钱，对我来说，服务器就一直在运转。”
在某些方面，这是非常正确的，Twitter的示例也证实了这一点：所有度量标准都表明，从开发人员的角度来看，一切都是有序的，但从业务工作的角度来看，则根本不是有序的。
老实说，我们都应该受到指责。 当然，主要负责生产监控产品的公司。 但是我们也一样，因为传统上我们收集系统指标。 我们习惯于使用小型系统-一台，也许两台服务器。 如果他们有效，那么一切都井井有条。
现在，我们的服务器要多于两个，甚至是十个，而仅测量系统的运行状况或程序的运行状况是不够的。 我们必须跟踪其他事情。
回到报价中，我没有为所有绿色的东西付费。 我得到报酬是为了让我的用户或经理满意- 有人应该对结果感到满意。 如果所有用户都不满意，那么没人会在乎一切都是绿色的。
业务监控
我们说需要监视，因为一切都在变化。 但是，当一切发生变化时，变化会影响业务：某些事物已经崩溃-资金停止流入，某些事物已经修复-资金又开始流动-直接相关。 或者他们不影响它-但是，如果我们不监控业务，我们就不知道。
作为一个生动的例子，每个人都熟悉缓存读取图。
90％的时间里，一切都井井有条，几乎所有请求都进入了缓存。 突然发生了一些事情-非常严重。 这个问题应该在凌晨3点醒来并解决。 但是，如果用户的下载速度没有变化，这真的有问题吗？
在英语中有一个术语“可观察性-可观察性”。 它们是：监视，记录，警报。 因此，术语监视有点。 我们希望观察所有内容-必要时收集每个节点上的系统指标。 但是我们要监视业务，因为它使所有人兴奋。 这是成功的指标。
为此，我们必须：
1.了解问题-我们到底需要监控什么。
2.确定基准-也就是说，足以确保用户的下载速度没有变化，以至于当从缓存中读取数据停止工作时，没有人在深夜醒来。
3.关联数据是最重要的因素之一。 如果市场营销收集有关收入的数据，而您在服务器上收集数据并且无法比较这两个观察结果，那么它们的意义就很小。
我通常会举很多例子。 不管它们看起来多么荒谬，它们都是我的生命，我为它们花费了很多神经。
示例：我有一个拥有1亿用户的客户。 这是一家互联网营销公司，发送了大量电子邮件并使用了A / B测试。 对于他们，我们收集了6000个指标。
一如既往，一切都始于通话。 电话响了-这意味着发生了一些事情。
“ 我们有问题。” 某事不起作用。
-好的，到底什么不起作用？ 这表示什么？
-我们开始收到较少的收入。
-还有？
-系统不起作用。
-我不明白。 如果收入减少，请与您的销售团队联系。 你怎么打给我
-不，我确定系统中的某些内容不起作用！
-好吧，让我们看看。
感谢上帝，我们有一个收入指标，因此我们可以看到。 该图确实显示，他们的收入在某些时候下降了15％。 给定用户数量，这是非常重要的。
好吧，我得看看。 首先，我检查下载速度-正常。
我们查看了数据库上的负载-一切都在合理的范围内，似乎没有任何变化。 然后，我们开始在各个节点，缓存中查看cpu负载。
一切都井井有条，直到我们了解了电子邮件通讯的指标。 大型提供商之一意外地将其域名列入了黑名单。 他们的电子邮件营销所占的百分比已不再覆盖用户，这意味着人数减少了：收到信件，单击按钮，访问该网站并购买了一些东西。
这是一个如此的关联！
幸运的是，我们有了这些指标。 如果我们没有它们，我们将其添加-这是一个非常简单的答案。
人们犯的最大错误是认为可以在项目结束时进行监视。 这就像一个功能：创建您自己的项目，进行监视-至此，我们已经准备就绪！
仪器永远无法完成。 始终存在从一开始就未知的问题。 与测试一样，您无法编写测试并涵盖所有内容，因为您不知道什么是“一切”。 我们不知道如何预测未来，也不知道如何预测业务，因此我们不知道什么是“一切”。
与我所谈论的完全相同的示例。 是首席执行官，他在早上在巴黎的一次会议上醒来，喝咖啡，看了他的邮件和损益表，并给我打电话时遇到了同样的问题：收入下降。
我记得很好，因为他早上有9点，而我还有6个小时，也有星期六。 我刚从一个生日聚会被带回家-但这没关系。 因此，凌晨3点，我坐在电脑旁，我们开始执行相同的步骤。 也就是说，我们只查看系统的负载，注册号。
我们发现的唯一偏离标准的是成功授权的百分比较低。 也就是说，数量相同，但百分比略低。 我知道这可能是垃圾邮件，等等。 但是所有其他技术指标绝对是正常的。 然后我们几乎要遍历数据库中的所有行，并尝试检查是否有任何东西可以抓住。 绝对没有！
我们在星期日坐了半天，星期一也坐了下来，但是已经确定问题不是技术性的。 让他们自己决定。 星期一在这里，我上班，来自其会计部门的一名员工给我打电话：
-听着，你能帮我吗？
-你需要什么？
-您可以从网站上删除美国运通卡吗？
-当然可以！ 为什么突然呢？
-您知道，我们在这里与他们争论，直到我们接受美国人
快递一般。
“我很抱歉问，你什么时候停止服用它们？”
-我认为在周末之前-星期五或星期六 。
在他们的正确思维中，没有人会对某种类型的信用卡的授权百分比进行度量收集！ 当然，在这起事件之后，我们出发了。
我为什么要告诉你呢？ 您必须首先查看业务，因为所有这些系统性问题都是看不见的。 他们没有在深夜醒来任何人，我们没有看到这些是问题。 很容易注意到收入下降，并且需要跟踪其他所有内容，以便您可以将此数据与业务数据相关联。
商业成功
对于企业而言，成功可能会有所不同；这取决于目标。 最重要的是，如何测量？ 传统上，我们有时以工程师的身份来衡量系统性能，而忘记了您可以衡量任何事情。
例如，您可以衡量自己的酒精中毒。 顺便说一句，我不是在开玩笑。 在我们的办公室里有四个水龙头的生啤酒。 由于我们都是工程师，所以我的同事决定戴上Raspberry Pi传感器，以查看我们喝了多少啤酒以及哪一种啤酒。
这看起来像是个简单的笑话，但实际上很方便，因为我们可以看到啤酒用完了，我们需要更换酒桶了。 一般而言，我们可以看到人们何时喝酒，他们最喜欢哪种啤酒-黑，浅等。 顺便说一句，高峰是我的生日。
绝对是偶然，我们为此找到了另一个应用程序。
该图显示了几天和周末的啤酒消费量。 到周末，酒精消耗通常会减少，几乎消失。 我们星期一有一天到达，查看时间表，看到星期六有人喝了四分之一桶啤酒。 该图显示了半小时内的确切时间。 原来，周六来的清洁工必须宿醉，所以他们宿醉。
开个玩笑，但最后他们遇到了严重的问题，因为通常在工作场所喝酒甚至是别人的啤酒都不好！
最后，任何指标都是有用的。 即使是我们纯粹为自己的粉丝收集的这一指标，在其他方面也很重要。 但基本上，真正需要的指标归结为金钱。 金钱对企业最重要。
通常，企业成功的标准最终会涉及金钱：
业务指标：
所有这些都具有等价的货币。 , , — , . , .
. . , , .
, — . , — , — , . , — 99- , SLA .
, , -.
, . , , , . , .
. , . . . , 3 , .
— . , , , , .
.
: , , , - .
, . , , , 50 % « », , .
1 ?
1-2 . . 10 000 , . , 10 000 , - .
1 . 600-700 . , 600 — , . , , . 800 , , — .
, , . 0 , - , ! .
, - . — , .
99- 50- , . , .
, — , DevOps — .
, , .
Value stream mapping — . , . , , , , , . , , .
:
- MTTD (mean time to discovery) — , .
- MTTR (mean time to recovery) — , .
- , .
- / .
, , , , . : « — . , , ».
, , . , .
. , — , , . , . .
— , , . , , , . — .
1 2 , DevOpsConf Russia .
DevOps, , , . , , .
, , .