The Tail at Scale，是 Google 2013 年发表的一篇论文，大规模在线服务的长尾延迟问题。
要知道怎么解决长尾问题，先要理解长尾延迟是个什么问题，在开发在线服务的时候，我们都知道要关注服务的 p99/p999
延迟，要让大部分用户都能够在预期的时间范围内获得响应。
下面是一个不同响应时间的请求数分布图：
大部分系统也都遵循这种分布规律，现在互联网的系统规模比较大，一个服务依赖几十上百个服务的情况都是有可能的。单一模块的长尾延迟会在有大量依赖的情况下，在服务粒度被放大，《The
Tail at Scale》论文里给出了这样的例子。
> 考虑一个系统，大部分服务调用在 10ms 内响应，但
偶尔讲讲工具，放松一下。
现在写技术文章不但要写技术细节，图还得画的好看。对于表达思路和架构来说，图确实挺直观的，这篇文章介绍一下常见的绘图工具。大家可以看自己的喜好自行选择。
在早期写 golang-notes 的时候，想要向那些写 RFC 文档和早期的 unix 大神们致敬，所以比较喜欢 ascii
图，这种图的好处是你可以直接将图表内嵌在文档内部，不需要有附件。有利于单文件传播。
用来画 ascii 的图工具有不少。
textik
textik 是一个在线项目：https://textik.com，可以直接在线绘制 ascii
1. 写作是单向沟通，读者读不懂，说明是作者没有写好。
2. 作者自认为的前置知识，可能在读者角度是不懂的。
3. 文章易懂，需要对读者的心智模型有一点了解。
4. 用总分或总分总的结构去写文章和做演讲；因为大家时间有限，可以根据你的总论判断是否要读下去，工作汇报演讲结论先行。
5. 观点不宜太多，如果太多，尽量划分到 3 类里。
6. 用段落组织文章，而不是句子(一些娱乐性的文章，可以用句子来组织。
7. 每段只写一个主题。
8. 每段开头是一句概要描述，后面段落补充细节，每段大约 4
本文是武汉 gopher meetup 的分享内容整理而成，分享内容在“无人值守”的两篇和其它社区分享中亦有提及。(也就是说你看过那两篇，这个可以不用看了)
先来看看苦逼的开发人员
老板说：
队友说：
外组同事说：
底层团队说：
你：
业界的思路？
混口饭吃也是不容易，既然有问题了，我们还是要解决的。要先看看有没有现成的思路可以借鉴？
Google 在这篇论文 [https://research.google/pubs/pub36575/]里提到过其内部的线上 profile 流程：
架构图已经比较简单了，线上应用暴露 profile
几年前在 oreilly 看到一本叫 《living documentation》的书，可惜当时烂尾了。
最近图灵出版了该书的中文翻译版，才想起来有这么回事。。。正好最近有时间，把这个坑了几年的东西给填上了。
简单来说，这本书基本可以叫 living java doc(误。我们可以先看看日常开发中会涉及到哪些文档：
* 需求文档
* 接口文档
* 业务词汇表文档
* 模块业务流程文档
* 系统间交互文档
* 系统架构文档
* 系统依赖文档
* 发布文档
* 示例文档(tutorial)
* 项目进度文档
* 案例文档
* 汇报文档
要写的类型文档还是不少的，无论哪种文档，
