逍遥子曰：

本文是对《架构即未来》一书第16章的总结； 1. 风险管理是提高和保持可用性及可扩展型的最基本和最重要的方面。 2. 测试是预先发现风险并有效降低风险概率的有效方法，但是任何的测试都无法彻底发现所有的风险点； 3. 在AKF中倾向于把风险看成一个“多元化的产品”，将风险分成两部分： （1）风险发生的概率，它有两部分决定： [1] 本次变更（版本升级）的变更量，即这次改动有多大？ [

本文是对《架构即未来》一书第12章的总结； 1. 书中总结了一个好的架构应该具备的特点，但是有些特点个人感觉是重复的，中间起来应该有以下3个特点： （1） 具体的、可执行的；好的架构不应有太多虚的东西，它应该能够切实可执行起来用于指导开发； （2） 可度量的；平时最关注的是一个架构所能承载的性能，它应该是可以测试出来； （3） 可达到的；架构设计不应脱离实际，一个很美好但是无法实现的架构是

我记得曾经读过俞甲子的《程序员的自我修养——链接、加载和库》，当时就觉得这个书名起的不太合适，有点不合主题，因为这本书主要讲述链接库的事情，我认为这个是编译器的一部分，是作为程序员要掌握的一项基本技能，而不修养的事情，更谈不上基本修养（但是这本书的内容依然是非常好的，我曾经仔细阅读过5遍，并且详细的做了笔记和心得，所以，我还是很认可这本书内容）。从那个时候起，我隐约也在想一个问题：程序员的基本修养

本文是对《架构即未来》第2章的总结 1. 团队组织的核心就是人员的管理问题 2. 规范和标准对于一个团队来说非常重要，个人理解，它能保障团队成果的质量底线，如果一个团队不能养成遵守规范和标准的习惯，那这个团队的产出成果就会良莠不齐；规范和标准是一个团队由游击队走向正规军的标志； 3. 团队中的任何工作都要职责清晰、明确；如果全凭自觉，靠吃大锅饭的形式，当任务下来的时候就不会有人觉得自己对

本文是对《架构即未来》一书第11章的总结； 1. 读完本章最大的收获是了解了应该如何评估一个系统的能力以及应该怎样为一个线上系统预留发展空间。在系统上线的时候，我们经常被问到的几个问题就是你的系统能承受多大的用户量？我们当前应该部署多少服务才能承载公司的当前和未来一段时间的业务？ 2. 文中给出若干步骤用于预估系统的预留空间，将其总结如下： （1）确定当前的系统负载量，包括了解系统的组成以

变更包含广阔的范围，它不仅包括软件的升级还包括对当前环境的任何软、硬件改动，包括配置、操作系统、数据库、防火墙、网络设备等等，对于研发来说，变更最主要的还是版本升级；生产环境的变更是事故发生的主要原因，经验指出，生产环境中的事故，有很大一部分是由于软、硬件的变更而引起；这也与我们的实际工作场景相似，我们在实际工作中，一旦遇到生产环境的问题，首先要问的就是最近有没有谁对系统做过任何改动？例如版本升级

本文是对《架构即未来》第8章的总结。 1. 书中的的问题翻译为根源更合适。 2. 故障是指造成服务异常的事件，包括停止服务、服务效率降低等；根源是导致故障的原因；同一个根源可能导致多种不同的故障； 3. 解决故障属于紧急事情，找到根源属于重要事情，在时间管理的四象限法制中，紧急事情优先级要高于重要事情；在实际工作中也基本如此：一旦运维发现线上服务出现问题，首先想做的事情就是重启服务，尽量

本文是对《架构即未来》一书第7章的总结与思考1. 个人认为书中的过程改为流程更为合适；2. 流程是什么？个人理解：为解决特定问题而形成的套路似的解决办法，只要大家遇到这样的问题，按照流程中的步骤一步步执行，就能确保问题解决。3. 流程能帮助我们做哪些事情？个人理解：（1）规范每个人的操作行为，让问题的解决更为规范、可控；其实每个人都有自己的主管思维和理解，每个人看问题的角度可能都不一样，他们所形成

第17章 性能测试 1. 性能测试是指把负载和用户需求施加在系统上，以测量其相应时间和稳定性的过程，它是为了验证应用能够满足预期的性能目标；一般需要关注响应时间、吞吐量和资源利用率这三类指标； 2. 性能测试的第一步是建立标准，没有标准的测试是没有意义的； 3. 性能测试的环境应该与研发、QA和准生产等环境分开；之所以要把性能测试环境独立开是因为性能测试需要对整个系统施加压力，如果系统中

最近在学习管理，《赋能》一书，对其思想没了解，虽然书快看完了，也没有get到点。该书以美军在伊拉克战争之后面临的团队组织问题以及通过打破团队界限，从而为团队注入新的活力。相反，今天看到一篇文章之后颇有感悟，该文章讲上次美国打伊拉克的战争中，伊拉克的坦克在掩体里防止被美军打击并待机大显身手，可是美军的空优非常明显，它从飞机上发射反坦克导弹，导致伊拉克的坦克全部被反坦克导弹击毁，毫无反手之力，就像...