一年多前，出于显而易见的原因，下定决心肉身翻墙。经过一番考虑，放弃了读书这条途径，决定直接找工作，通过H1B签证出去。于是去年八月份从百度辞职，开始着手准备。当时觉得今年拿到H1B的成功率大致能有个六七成，加上周围朋友们的不断鼓励，可以说还是相当自信的。然而，时至今日，在历经Google、Amazon、Facebook三家公司之后，这第一次尝试却可耻地失败了……

    一般来说，即时通讯(IM)软件都会对客户端到服务器的通讯进行加密，对用户隐私数据安全提供一定程度的保障。但也有例外，比如MSN就完全不加密。所以一些小公司将MSN作为主要IM工具是极为不明智的，借助Wireshark等简单工具对员工间甚至员工和客户间的对话内容进行监听易如反掌，极容易造成商业机密的泄漏。微软坚持使用明文MSN协议的目的让人难以捉摸，其中恐怕难免混有政治因素。使用MSN Shell插件的加密功能或者SSH隧道转发等手段，也可以不同程度地间接加密MSN通讯数据。即使是那些号称使用加密协议的IM服务，也并不真的就百分之百地安全，在国内的网络环境下尤其如此。一直饱受质疑的QQ(1、2)自不必说，国内其他的IM运营商也多少存在类似的境况。这种行为固然可恶，但作为国内的运营商，若不如此便无法生存——饭否便是个极好的例子。

    之前在Twitter上说过，打算写一个个人数据安全解决方案的系列，内容包括： 基于GnuPG的个人隐私数据保护自建XMPP服务器保障即时通讯安全使用Dropbox进行较低密级的文件共享和协作(后记：事后觉得Dropbox这个话题太简单了点，没啥好写的，且重点在共享和协作，而非安全，便取消了。) 原本还打算写一写用SSH端口转发隧道建立SOCKS v5代理(俗称SSH翻墙术)，鉴于网上已经有不少不错的介绍(1、2)，就不再重复劳动了。这里所采用的技术全部基于开源软件、免费软件或免费服务商，同时也兼顾使用体验。除了自建XMPP服务器所需的域名费用外，其余部分的经济成本为零。 跟丫头暂时还维持着北京、杭州两地分居的状况，网络是平时联络和数据交换的最为重要的手段。上述的这些技术都是我们目前正在使用的数据安全保障手段。

    6月29日，Amazon EC2美国东部1号区域的一个availability zone遭大规模雷暴袭击而断电，该事故殃及了包括Netflix、Instagram、Pinterest在内的一大批服务，详情参见Amazon针对此次事故的官方报告。几天后，偶然在Channel 9上看到一篇文章，进而顺藤摸瓜找到了Richard Cook的这篇发表于1998年的How Complex Systems Fail。这篇文章总结了十八条关于复杂系统故障的经验，言简意赅却一针见血，读之让人击节叫好，大有拨云见日之感。回顾Amazon针对这次事故的官方报告，以及自己在过去若干年间遇到的种种线上事故，几乎无不落入这十八条之内。这篇文章并没有将视线局限在技术领域，而是从系统、从业人员、事故评估等一系列角度全方位地探讨了复杂系统故障的性质，点破了复杂系统中的一系列“潜规则”。