找了一张一堆娃娃的照片当题图，估计这次又会有人给我留言说我的题图是乱入了。看完文章就明白了，这次真不是乱入。

娃夜里哭，或者 oncall 夜里接到电话，就注定那夜，美梦将无法继续。

注1: 估计程序员都知道 oncall 是怎么回事。说白了就是值班，那几天系统出了问题会自动通知 oncall 的工程师。通常用的 App 叫做 pagerduty，可以设置成出问题时打自己的电话。Oncall 的人得保证随叫随到，所以取名叫做 oncall。

先吐个槽。春节那一周，赶上我 oncall，然后好巧不巧的女儿又发烧咳嗽。小孩一生病，大人夜里总没什么觉可睡，断断续续的，一夜就打那么几个盹。再加上还有两三次因为 oncall 半夜被电话吵醒。所以那几天睡眠严重不足，一夜可能连四个小时都不到，还是不连续的。好在我睡得少成了习惯，所以白天忙起来倒也不觉得特别困，一天再多喝个两三杯咖啡，一周居然也就这么撑了下来。

人在一些基本需求不能被满足的时候，就对一些很普通的事产生极强烈的渴望。当你为了减肥克制饮食，就会想着要是有机会能大快朵颐，吃个火锅，喝个啤酒，应该是人生最大的快事了；当你因为摔了腿，一时不能自己走路，就会想着，能够自己健步如飞，蹦蹦跳跳，真 XX 的痛快；当你手指绑上创可贴，打字别别扭扭的时候，就会想，哪都不受伤的时候真好；当整个城市都是雾霾，出门都要带口罩的时候，就会想，要是有口新鲜空气气，能看看蓝色的天，真是人间最美好的事。。。

所以，当我一周处于被虐没觉睡的时候，我在开车的时就会一直幻想着，自己哪天突然生活就变了，天天能睡个饱觉，应该是最幸福的事了。

后来娃好了，oncall 也交接了。周五晚一觉睡了整整八个小时。醒来的时候，高兴的都快哭出来了。睡够了，就发现，哦，原来自己还有别的追求，我的幸福，肯定不止于只是天天睡够觉。

关于 babysitting

Babysitting 这个单词，我是来美国之后才学到的。什么意思呢？baby，就是娃；sitting，就是坐那。合起来就是坐那看娃。这娃可能是自己的，也可能是别人的。可能是一两个，也可能是六七八九个。可能是看一个小时，也可能是看一天。这段时间，娃哭了闹了，你得管。如果是饿了，给点吃的；渴了，给点喝的；尿尿神马的，自然也是得伺候着。但是如果哭闹是因为生病了，或者不小心受伤了，就只能通知家长了。

Oncall 这件事总让我不由自主想起来看娃。怎么说呢？Oncall 期间负责的系统可能是你自己参与开发的，也可能是公司别的组开发的。可能为一个系统 oncall，也可能为全公司多个系统 oncall。可能是按天轮换的，也可能是一周轮换一次。这段时间，有些问题，你重启下什么，或者按几个按钮就解决了。而有一些问题，你就只能通知系统的 “家长” 了。

所以这么看来，不论是Oncall 还是 babysitting，最重要的一项技能，不是你厨艺医术等样样精通，而是出了问题时，能够快速发现问题，诊断问题，和托付问题。

关于 oncall

今天也就就这个机会聊聊一个公司，尤其是中小规模的公司，通常 oncall 的系统里都涉及到哪些工具和基本套路吧。

Monitoring for Alerting

首先的一项就是系统的监控（monitoring）和报警（alerting）系统。这通常包括三个部分。第一，是将系统和选用的监控工具集成。第二，在代码中加入各种 instrumentation 向监控发送数据。第三，在监控系统中设置各种阈值，当某项指标出现异常时，通过特定的方式通知预设的组或者工程师。

那么如今比较常用的 Monitoring 和 Alerting 都有哪些呢？据我所知，硅谷大部分公司 Alerting 都是用的 PagerDuty，它有一个手机 app，当 oncall 被 page 的时候，可以快速方便的用手机做出 ack 回应，以及问题解决后的 resolve。可以设置 alert 类型，这样除了 app 通知，还可以发送短信或打电话。

现在很通用的 Slack 便有和 PagerDuty 集成的功能，这对于 incident 时组员间的协调和通信起到了极大的助益。

当然，我听说硅谷老大 Google 并不用 PagerDuty。这就是 Google 的神奇之处了，基本我们用的开源工具他老人家都看不上，非得自己整出一套内部的系统。不过这也好，很多 Google 工程师都在做各种他们自己的工具，一定程度上解决了部分码工的就业问题。但问题是整出来好东西他老人家也不和我们共享。但是也听说他们的 Alerting 系统只有 android 上的 app，并没有 iOS 上的。听说是 Apple 就是没给他老人家批准让 app 进 store。所以 Google 用 iphone 的员工 oncall 的时候听说只能被打电话了。

注：嗷哦嗷～ 一口气用这么多 “听说” ，大家也就只好当是听我说说咯～

再看看 Monitoring 的工具。

下图是一篇博客（链接1） 2014 年对六十家不同公司使用的不同的 monitoring 工具的一个使用频度的统计。因为签署了保密协议，所以并没有提出是哪六十家公司。但是我觉得该图还是具有一定代表性的。

链接1: ［What we learnt talking to 60 companies about monitoring］https://blog.dataloop.io/2014/01/30/what-we-learnt-talking-to-60-companies-about-monitoring/

从图中可以看到，用的最多的似乎还是 Nagios，Graphite 和 New Relic。其中 New Relic 感觉最好用，但是贵的要死，所以好些经济不那么宽裕的公司只能不用或使用免费版的。另外，很多公司的 Monitoring 系统都不会只用一个工具，通常是两到三个并用。因为这些工具都有不靠谱出问题的时候。

具体的每个工具的优缺点，Google 一下很容易找到。还有一些如今很常用的 Monitoring 工具上图都没有提到。出于种种考虑，我还是不在这里一一列举了。

Logging for Investigation

一旦知道系统出了问题，下一步就是去检查到底是哪里出了问题。这可能是因为网站的访问量正常或非正常的突增。正常的突增就是访问高峰期的时候，或者公司 campaign 活动期间的访问量的增长。非正常突增可能是因为 scrapers，或者是 DDoS 攻击等等。

也可能是最近的一个代码改动触动了一个问题，或者是之前的代码改动引入了一个隐性的 bug，这 bug 在当前特殊的应用情景下被触动了。

还有可能是一个依赖的第三方服务突然挂了，比如 AWS 等等。或者是数据库出现了某种 N+1 query 造成整个网站的访问延时。或者是集群上的 garbage collection 导致的问题。或者是系统某个硬件挂了等等等等。

总之，系统的问题千奇百怪。很有经验的工程师可以很快的排查出问题出在哪。而即使是有经验的工程师，也不得不借助 Monitoring 工具以及各种系统 log 提供的信息，才能做出正确的判断。

用来做 log 的系统更是多种多样，很多都是可以用 ElasticSearch 等用来做索引或者快速查找的，比如 kibana。 这篇文章中提到的几个工具也是用的比较多的几种：《The 7 Log Management Tools Java Developers Should Know》（链接2）包括：Splunk，SaaS，Loggly，PaperTrails，Storm，Logstash，Graylog。文中对几种系统也进行了优缺点比较，我这里就不展开。

链接2: http://blog.takipi.com/the-7-log-management-tools-you-need-to-know/

System Control

这就包括 shutdown 部分系统、或者系统的部分功能，重启系统，以及 launch 某项特定的服务等。这一部分至关重要，好的系统控制的实现能在系统出问题时最大程度地减少系统的 downtime。但是这一步的实现没有一个开源的或者统一的解决方案，而是要靠各个公司的工程师们自己实现出来了。

嘀嗒嘀嗒：讲述技术、白话硅谷。偶尔八八程序员身边的事儿。关注长按二维码：