从前年开始，我开始用 GitHub issues 写博客，写到去年的时候，逐渐意识到，GitHub issues 还是有一定不足的，比如一个很关键的点：无法查看有多少人看了你的博客文章之类的运营数据，所以那得使用 Google analysis 之类的分析工具。

又是一年过去了，在这一年里，似乎很多事情还处于未完成状态，但是，时间不等人，掐指一算（打开了 Excel），我的人生也已经过去了 10000 多天，至少三分之一已经入土 (是的，扎心了）。

• 原文：https://www.targetprocess.com/articles/speed-in-software-development/
• 作者：MICHAEL DUBAKOV
• 译者：xizhibei

译者边注

这篇文章是几月前看到的，现在打算翻译一下来回顾以及加深里面的内容，作者以系统思考的方式论证什么因素对于软件开发速度是重要以及不重要的，以及它们之间的复杂关系，文风诙谐幽默，可读性非常高，最后相信你会从线性思维方式的方式转变过来，能够认识到软件开发速度不是单单靠某个因素就能提高的。

每一个 IT 公司的 CEO 都希望开发软件的速度能再快些，而时间又是最昂贵也是最有价值的资源，因此你不能把它浪费在返工、重构、开会甚至体育活动上面。是吗？看情况。

Kubernetes 发展好快，在我写这篇总结的同时，1.9.0 版本已经在昨日（2017.12.16）正式发布，而上次在正式环境中部署已经是半年前了，我花了点时间将集群升级到了 1.8.4 版本，其中变化最明显的就是权限了，已经可以用上 RBAC 了，而我也在发现报错的时候才意识到需要将以前 k8s 的基础应用也全部加上了权限（当然了，1.6 其实就开始有了）。

我们经常说，人才是企业最重要的资产，只是，现实中，我们很多时候都是把这句话当口号而已。

在你反驳我之前，我希望你仔细想想下面这几个问题：

1. 你们的招聘流程是怎样的？你们是根据什么具体标准面试求职者的？

今天给大家来介绍一个报警工具，具体来说，是基于 Elasticsearch 的报警工具，假如你的日志是放在 ES 里面的，这个工具是你不错的选择。

• 项目地址：https://github.com/Yelp/elastalert

一直以来，我没有总结过 Gitlab 的部署，而在以前的文章中，我不止一次提到关于 Gitlab 在我们整个交付流程中起到的基础性作用，以及它为整个公司的开发带来的巨大效率提升：

这周去参加了 QCon，涨了不少姿势。但是最有收获的反而不是纯技术方面的，而是与技术相关的内容。其中最有意思的是 @邱岳 的『怎样构建产品和技术之间的合作氛围』，那天本来想听听别的场次的技术内容的，但是一看一个熟悉的名字『孙志岗』，这不是大学老师么？那是我拿到最高分课程的操作系统老师，太巧了，于是就奔着老师去了。他是这个场次的出品人，听了之后，觉得很受用，非技术出身的讲师反而在演讲反面更有优势：口才更棒，演讲更吸引人。

不知不觉，『嘟嘟美甲』这个名字，现在已经很少有人知道了，就如那些被淘汰的大多数公司一样。这是一家在 O2O 浪潮之中的一家提供上门美甲服务的公司。

眼见他起高楼

记得那时，是毕业一年之后，只是因为在外企呆的太郁闷，不开心，于是，在 CEO 口头给了期权之后，便加入了。应该说这是大学里一直想做的事：毕业之后去一家创业公司。

我觉得，这一两年我学到最有意义的工作方法，便是： 妥协 。

招聘

以前经常说，一定要招聘优秀人才，不优秀的不能接受，这原则本身没有问题，问题在于，我们把很容易把缺乏实际开发经验的『不够优秀』的职场新人也淘汰了。现在回头想想自己，当初我们刚入职场的时候，不也是菜鸟一个么。

往往，在我们的开发过程的以下两个场景中，我们会需要去分析应用的性能。

1. 开发时候优化程序；
2. 线上排查问题；

之前在 《应用配置管理实践》 中提到过配置的管理方式，这次我专门来说说在工程实践中总结的一些应用配置原则。

自从 上次 介绍了 Prometheus 之后，就想到要在 k8s 中使用了，不过，在这之前，先介绍下 k8s 的监控。

一直以来，我们会在项目中，使用 APM 去监控应用的状况，分析性能等，这些工具很有效，而且不侵入业务，不需要埋点。

然而，有些需求，是 APM 的监控满足不了的，比如 应用业务指标 。

最近公司的领导开始重视服务器的稳定性了。

这是件好事: 因为受到重视，意味着这方面有领导关心跟过问了，对于提高服务器稳定性，大家也都会有更多的压力与动力去做好；这又是件坏事：毕竟是由于历史上出过问题，才导致的，也就是说，之前大家做得不好。

SLA 这个数值很有意义：让大家对服务水平进行承诺，对于公司的减少损失很有帮助。只是对我来说，这件事本身让我有些反感：上级想把 SLA 写到 KPI 每月考核里面，且不说 KPI 考核对于创造性从业者的各种伤害，单是每个月将服务器稳定性加入每月考核 KPI，就有些不合理了。