说到大规模集群管理，就离不开运维自动化。一个人手工也许可以运维几百台机器，但是随着集群规模的增长，我们需要的是一个人运维数万台机器。 这在大规模集群管理中是一个常见的问题。因此，运维自动化是一个很重要的事情，这也是为什么很多公司原因上云，因为上云之后运维的问题就托管给 云平台了。这也是云平台这么贵还能卖的这么好的原因。
运维自动化的问题到底是一个什么问题？我认为，可以拆解为以下子问题：
自动发现错误
自动修复错误
安全（Safety而非Security）
这里的每一个问题都是复杂的，困难的问题，远非表面上看起来那么简单。以下仅作简单的展开，提供一些思路。
Autopilot是微软Bing组研发的集群管理系统，至今已有近20年的历史。Autopilot是一个内部模块高度解耦，完善发达的系统，其设计目标是自动化的管理静态集群。自动化的好处有以下几点：
节省人力
响应速度和处理时间优于人工处理
所有的处理过程都有Audit
不易出错
本文从CAP理论和ACID性质为切入点，讨论分布式（存储）系统的设计。
分布式系统，尤其是分布式存储系统，在进行设计考虑时，首先需要想到的就是CAP问题，即在C（Consistency）和A（Availability）之间如何进行取舍的问题。我在思考的过程中发现，尽管对于Consistency有着诸多分类，如Linearizability、Sequential Consistency、Causal Consistency，但是对于Availability却没有一个对应的分类。这有悖于对CAP理论的理解：我们降低了Consistency之后，能得到什么程度的Availability？更进一步的，我们降低了Consistency后，是否真的能够提高Availability？
哈希表（hash table）是一种快速查找场景下常用的数据结构，本文对其主要问题及其高级应对方法进行有限的总结和讨论：
负载不够均衡，此时会有哈希冲突（collision）出现，导致哈希表性能下降
负载高时，若不进行空间扩展则性能下降，若进行空间扩展，扩展行为的（瞬间）代价通常较高
用 C++ 语言也有一些年头了，在此总结一些工作中比较实用的 C++ 的功能子集。这里的主要使用场景是系统编程，不包括各种通用类库。
我认为每个程序员都应该会点形式化证明，这有助于思考，更有助于写出正确的实现。
这是一篇关于单机存储引擎基本思路的总结和分析。
F4 是 Facebook 为了降低存储成本而开发的，应用于只读可删除不可写场景的，对象存储系统。
Haystack 是 Facebook 为了其图片存储场景进行特殊优化的热存储系统，系统接口是简单 Key-Value 存储。论文主要描述了其单机存储引擎的构建，针对一次写入多次读取从不修改的场景进行优化。本笔记只涉及到论文中单机存储引擎的部分。