认识达内从这里开始

对于运维程序员来说，程序员出错或者是出现问题都是非常常见的情况，而今天我们就一起来了解一下，面对程序出错问题都有哪些解决方法。

程序出错的时候

当事情出错时，而且一定会有出问题的时候，黄金法则是将对客户的影响小化。

当事情出了差错，我自然倾向于赶快解决bug。事实证明，这并不是理想的解决方案。与其修复哪里错了，即使只是「修改一行」，所做的一件事应该是回滚版本。回到之前的工作状态，这是让客户恢复工作快的方法。

过了这个时候，才应该看看哪里出了问题并修复那些bug。

在你的集群中出现一台「垮掉」的机器也应当是同样的做法——在试图找出机器出了什么问题之前，先把它停了，并标记它不可用。

先找bug这种本能会引导我走上解决bug的漫长旅途，反而偏离了让客户先恢复工作这一理想的目标状态。有时候，我觉得它没有工作的原因是因为写的代码有问题，而仔细阅读每一行代码后会陷入混乱，像是一种深度优先搜索。

之后，我的启发是，先开始广度优先搜索，然后再深度优先搜索，去除顶端的节点。能否用已有的资源确认：

机器启动了吗?

是否安装了正确的代码?

配置是否正确?

<代码特定配置>，像代码中的路由是否正确?

模式版本是否正确?

然后进入代码。

在某次出错的问题上，我们以为机器上没有正确安装nginx，但结果是配置被设置为了false。

当然，我不需要总是这样做。有时候错误信息已经足以减少需要搜索代码的区域。而且当我无法解决这个问题时，我尝试并持续修改代码以将问题降到低。修改的次数越少，我就能越快地处理实际问题。

但是我现在还是会记录花了1个多小时来解决的bug：遗漏了什么?这通常是一些我忘记检查的愚蠢错误，比如像设置路由、确保模式版本和服务版本匹配等。这是熟悉使用的技术堆栈的另一步，而且只有经验会告诉我为什么系统无法运行。

监控

这是我以前从未想过去做的事。说句公道话，在全职编码之前，我从没维护过系统。我只是搭建它们，使用1个星期后然后进行下一项工作。

有两个系统，一个有良好的监控，另一个并不那么好。我逐渐非常喜欢监控。如果我不知道bug在哪我就不能修改错误。其中一种糟糕的感觉是从客户那里知道有bug。

「我做了什么?!我甚至不知道我的系统出了什么问题?」

我认为监控由3个部分组成——日志、衡量标准和警报。

日志

以代码中进行日记记录就像人写日志一样，是一个进化的过程。

你要找到你可能需要监控的东西，日志记录下来，运行系统。一段时间后，你会发现你没有足够信息来解决的bug。这是增强日志记录的好时机——你的代码少了些什么?

我想你会凭直觉地知道什么东西很重要需要记录，但是在我们的服务器中我和资深软件工程师所记录的东西有很多不同。我认为只要请求-相应日志就足够了，但是他会有更多的记录内容，比如查询执行时间、代码进行的一些特定的内部调用，以及何时转储日志。一切都已经解决了。

几乎不可能在没有日志的情况下进行调试——如果你不知道系统的状态，你怎么重新创建它呢?

衡量标准和惊爆

衡量标准可以源于日志，也可以独立于日志(例如向AWSCloudWatch和Grafana发送时间)。你可以决定你的衡量指标并在代码运行时发送数字。

警报是把所有东西整合到一个的强大监控系统的粘合剂。如果一个衡量标准是当前产品中运行的机器数量，当这个数字降到50%时，这是一个很好的警报——你知道有什么出错了。

失败计数高于某个阈值时?是的，又一个警报。

这里暗示了另一个需要养成的习惯。当你修复bug时，你不仅仅关注如何修复bug，而是你为什么不早点发现它呢?是否有布置警报?如何能够更好地监控来避免类似的问题?

我还不知道如何监控UI。即使吧组件测试到位，也还不足以了解出错的情况。这些错误通常是由客户来告诉我们的——这看起来不太对劲。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。