秋招才刚开始，原则上是不应该放面经的。我个人十分不赞成投机取巧，知识面狭窄的问题，绝非面经能够解决，有时可能适得其反。
无奈的是应该有不少实验室做的研究和业界(客气点说)实在不太对口，相信大家在内推阶段或多或少的遇到过类似的困扰，面试不好并不是我平时偷懒，而是因为面试官只问他们感兴趣的/擅长的，对于自己不懂的，总有那么一点“不屑一顾”的感觉。
我的个人经历证实，这些情况确实是存在的，大多数面试官还是会尝试让你去解释研究工作(虽然对方并不一定感兴趣)，只不过此时更多考察个人的表述能力。
时值秋招，offer拿得还算顺利，所以也没有特别大的压力了，这段时间刚好可以加强一下理论的积累。
下午听了一个和CAP相关的讲座——《CAP Theorem and Its Implications for Building Robust Distributed Systems》，当然主要还是介绍CAP Theorem，基本没怎么涉及“健壮的”分布式系统，毕竟1个小时也分享不了多少内容。
虽然网上已经有不少关于CAP的文章了，但和这次讲座上提到的相比，似乎存在一些问题，并不是说做学术的就是权威，大家需要自己斟酌。
关于容器技术的原理，我在很早之前翻译过命名空间相关的文章，但这还远远不够，需要切入的还有cgroup、文件系统和网络相关方面的细节。
到了招聘季，稍微有点时间整理这方面的资料，索性先从文件系统入手，本文的目标仅仅是“知其然”。
最近在写一个新程序，由于需要依赖平台相关的特性，因此每次提交前都需要手动在各种平台测试，令人十分苦恼。
好在，最近在实验室的一台主机上装了ESXi，虚拟出几个节点别提有多方便，所以CI也可以搞起了。
目前(一直以来)比较流行的CI有Jenkins，那就先从Buildbot开始吧。
读研以来，很少关注高层架构的变动，所以忽略了期间服务化趋势带来的一些变化。近期，在某厂的面试中就被问到了服务调度和容错。
目前，各厂基本都已进入了服务化的阶段，对于单节点的性能挖掘变得不再是那么迫切，服务调度、容错等问题才是焦点。之前通过开发服务器，基本掌握了Linux用户态的程序开发，但对于服务化方面的知识和经验，还是相当欠缺。