马斯洛语录：如果你的手里只有锤子，那么你的眼里只有钉子.

其实也就是人的本位思考能力，屁股决定那脑袋。

事件管理的宗旨是最短时候恢复故障，从而将故障的损失降到最低，在此前提下尽可能满足服务的要求。因此，事件管理突出的就是恢复企业的业务，启用备份，容灾系统等手段，第一时间采取各种措施来恢复企业生产，这就要求服务台将紧急故障定义为最高优化级，从而确保工单的快速流转，通过各IT部门密切配合来排除故障。
当紧急故障得以处理，信息中心就会转而进入问题管理的层面，以便找到故障发生的原因，从而改变频于应付突出事故的局面。与事件管理的根本区别就在于，事件管理目的在于恢复企业生产，而问题管理在于找出IT故障的根本原因，制定解决方案，防止类似故障的再次发生。

1、许多项目环境需要引入某种形式的变更管理工作流，或者说所有的变更需要经历多个阶段（比如开发、测试、生产上线）以及相应的许可批准从而进行至下一阶段。这一问题通常被称为变更管理(Change Request Management)。

变更可以是开发系统上的某个配置更改，某个代码commit或是若干bug fix的集合；变更具有不同类型（来适配对应的生命周期）；变更可以来源于某个issue，或是某个新功能需求。变更管理会涉及特定的人员角色如变更经理(Change Manager)等履行不同的职责。 (http://projects.puppetlabs.com/projects/1/wiki/Change_Management)

构建这一流程的优势在于：减少变更对于业务的影响、增加变更的透明度和沟通、减少可能的变更撤销、适应大规模的变更、为进行影响分析（impact analysis）提供可能

Q:在你的项目经验中，对于变更的管理是否应用了简单的issue tracking之上的具体流程？

2、我会假设一个软件项目的系统环境是三层系统架构：开发(Dev)——测试(QA)——生产(Prod)。在现今互联网应用前所未有复杂，对业务空前重要的情况下，在部署系统更新或例行配置更改时我们必须保证配置或更改对于所有特定的环境（数据库，Web Server、Application Server或者Middleware Container）都是正确的；然而，如果存在一些没有列入文档、不遵循流程的手工更改，要识别一个在QA系统上测试通过的应用和在生产环境上的那份程序是不是相同版本会很困难且容易出错。而且撤回上一次更改重新迭代的情况也屡见不鲜。

作者结合阿里巴巴在架构转型的经验，谈了阿里从单体的架构转型到分布型架构的历程。书名中提到的中台，其实是阿里的IT架构中的中台，按作者的说法就是共享服务（IT服务）中心，具体见下图：

本书总体的思路是，见下图：

SPU = Standard Product Unit （标准产品单位）
SPU是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性。
通俗点讲，属性值、特性相同的商品就可以称为一个SPU。例如：iphone4就是一个SPU，与商家，与颜色、款式、套餐都无关。
SKU=stock keeping unit(库存量单位)
SKU即库存进出计量的单位， 可以是以件、盒、托盘等为单位。
SKU是物理上不可分割的最小存货单元。在使用时要根据不同业态，不同管理模式来处理。在服装、鞋类商品中使用最多最普遍。
例如：纺织品中一个SKU通常表示：规格、颜色、款式。

1 引言

1.1 编写目的

为了方便大家以后发现进程假死的时候能够正常的分析并且第一时间保留现场快照。

1.2编写背景

最近服务器发现tomcat的应用会偶尔出现无法访问的情况。经过一段时间的观察最近又发现有台tomcat的应用出现了无法访问情况。简单描述下该台tomcat当时具体的表现：客户端请求没有响应，查看服务器端tomcat的进程是存活的，查看业务日志的时候发现日志停止没有任何最新的访问日志。连tomcat下面的catalina.log也没有任何访问记录，基本断定该台tomcat已不能提供服务。

2 分析步骤

根据前面我描述的假死现象，我最先想到的是网络是否出现了问题，是不是有什么丢包严重的情况，于是我开始从请求的数据流程开始分析，由于我们业务的架构采用的是nginx+tomcat的集群配置，一个请求上来的流向可以用下图来简单的描述一下：

做产品的同学在产品上线后经常离不开一个词，数据分析。那么要如何进行数据分析呢？不妨先问自己这么几个问题。
1.你要分析什么问题？是找问题还是验证？
2.关于这些问题你需要哪些数据？
3.这些数据从哪里来？

要怎么解决这些问题呢？答案是数据埋点。首先通过产品定位及目标来确定自己需要哪些数据，其次通过在产品各个流程环节中设置数据埋点，最后，当用户使用产品时，后台就能源源不断地接收到数据了。

本文对比了Zookeeper、etcd和Consul三种服务发现工具，探讨了最佳的服务发现解决方案，仅供参考。

Diamond则是淘宝开源的一种分布式配置管理服务的实现
disconf是来自百度的分布式配置管理平台,包括百度、滴滴出行、银联、网易、拉勾网、苏宁易购、顺丰科技 等知名互联网公司正在使用!

雪崩时，没有一片雪花觉得自己有责任。
出处，汉娜的平庸之恶。
It's actually by the modern Polish poet Stanislaw Jerzy Lec, from his 1968 "More Unkempt Thoughts".
后来，人民日报的微博，改写成，雪崩时，没有一片雪花是无辜的。