好吧，又是个比较蛋疼的经历。后来由于发现 Azure 的香港线路非常不友好（电信），最后还是迁移到了 Google Cloud Platform，话说我真的不想再迁移了。

有国际信用卡还是方便的，根据我目前的配置 Google Cloud Platform 几乎可以实打实用一年。据说 Google Cloud Platform 的流量费用还是不便宜的，所以到时候做些必要的优化（虽然访问量其实不高）。后面的具体费用，等账单出来以后再观察。

如果您能看到这篇博客，那么说明站点迁移到 Microsoft Azure 已经完成了。

其实并不是原先的 Linode 空间不好，而是某些不可抗力导致 Linode 日本节点在中国大陆的可用 IP 越来越少。顺便说一句，Vultr 更甚几乎可以说是全军覆没。

虽然相比 Linode，Azure 的性价比并不是很高，但是它有个「东亚」节点（其实就是香港）对于国内线路优化很好。如果不考虑性价比这块的话，Azure 其实也算是个很好的去处。

那么为什么不迁移到阿里云的香港节点呢？嗯，咱聊点别的吧…

当初组建家庭网络的时候，就考虑到自己的需求：主要是网络存储、以及跑部分比较耗时的「定时任务」，例如爬虫和下载还有部分的数据处理等。

本来考虑部署一台性能相对比较好的服务器去处理，但这样子考虑到部署太过中心化不好管理，同时硬件的成本有些高而且占地的面积太大，因此就暂时被我搁置了。

后来想到 空帷 的朋友圈，使用「树莓派」这个方案相对比较轻量，同时多出来的「树莓派」还可以用来它用，因此考虑使用「树莓派」搭建自己的家庭网络服务。

下面是简单的网络拓扑图，同时主要说明下图中的内容：

• 其实一开始组网的时候就使用了软路由的方案，所以路由器的性能并不差，但由于网络基础的缘故，还是不想过多的在上面部署太多的服务；
• 使用了 USB 协议的的 RAID 磁盘阵列柜，没有使用 NAS 的原因是当数据恢复的时候可以当作普通的 USB 外接硬盘来恢复、简单便捷；
• RAID 阵列柜和一个树莓派链接，上面跑了 Netatalk、Samba 以及 Syncthing 等文件服务，速度肯定没有 SATA 协议的快，但是家庭网络中 USB 速度不是瓶颈；
• 将下载、数据等应用服务分别使用了其他的树莓派去部署，平时如果不用直接插拔硬件即可；
• 装修的时候就单独开了一条电路用于 UPS 不间断电源使用，因此树莓派以及无线网络放大器可以不用放在同一个地方；
• 目前，将负责文件管理的树莓派同时用于管理 UPS 等，只要家中电源中断或者电压不稳，发送局域网广播通知应用应用服务下线，并切断 USB 阵列柜的电源；
• 考虑加树莓派链接电视，部署视频点播等功能，淘汰目前的小米盒子（爱奇艺在盒子上还需要重复收费，这块的费用不低）。

顺便说下，基于「树莓派」我已经写好了几个 Docker 的镜像，主要是文件管理（Netatalk、Syncthing 等）。可以直接拿来部署使用，不用重复造轮子啦：

1. https://github.com/mingcheng/raspberry-pi3-syncthing
2. https://github.com/mingcheng/raspberry-pi3-netatalk

- 未完待续 -

已经正式从丁香园离开两个月，时间过得很快。

说起来离职的过程并不算是十分得愉快，然而两个月过去了心态也平静了很多，应该可以从初心上去写点文字回忆在丁香园的这段时期。

初心

2010 年的时候，@Fenng 来找我问有个项目你或许可以试试，这家公司的名字叫做丁香园。那时候个人个人在阿里的时候正处在转型期（瓶颈期？），所以抱着聊聊看的心态和创始人 李天天 一起吃了个吃饭。

印象很深，这顿饭吃完了以后，我自己就有感觉是应该为自己的理想和初心去实践些什么。后面的一来二回持续沟通了以后，就做下了这个决定：离开阿里去当时这个没任何名气的小公司见证团队从小到大的过程。

我当时在博客里说明了我离开阿里的想法，私底下很多朋友和同事很不解我的决定。毕竟，在阿里（淘宝）四年的时间不算短，无论个人发展方面还是待遇方面，当时的丁香园是没有任何优势的。

然而，时至今日我还是坚持我这个决定，并不后悔。

技术

在淘宝做了四年的前端，来到丁香园的时候整个公司的技术团队不足十人。技术方面，由于丁香园在前端方面是没有任何的框架以及代码规范可言，业务的高速发展对于优化和重构这块是势在必行的。

现在回过头来想，开始我可能过于理想化以及出于技术方面的思维惯性（说白了就是没经验），还是沿用了淘宝的技术架构。

在前端框架的选型上，使用了淘宝前端团队自己编写的 KISSY，这个后来是个大坑。KISSY 无论在框架的接受程度上还是可维护性、扩展性方面，相比当时业内的通用知名框架没有任何的优势可言。

甚至在一段时间内，我还在和团队的其他前端逐个在说明 KISSY 框架如何使用，乃至至一段时间内都影响到了业务的发展。

悬崖勒马，经过考虑团队还是重新选择到了 jQuery 框架。好在当时的业务高速发展，冗余代码迅速被迭代才没有被后来的绝大多数前端们发现竟然还有这段黑历史 :^)

然而由此带来的影响，再后来 node.js 等推出和成熟，在技术方面的由于前一次的“吃亏”，团队并没有坚持选择非常新的技术。

PHP 作为前端和后台的“粘合剂”，在丁香园的服务器中存在了很久一段时间（至今历史代码还在）。

疲于应付业务和需求技术方面在很长的一段时期是没有任何的规范可言，这可能是小团队的通病。

客户端的兴起，业务驱动个人逐渐技术方面转向了客户端这边。因此，比较遗憾的是前端这边并没有推动太多新的技术和流程，然后又要去挖移动端这个“坑”。

在丁香园的六年多，可以说有 70% 的时间都给了移动端这边：团队、技术、架构、甚至采购。这一切的内容对于我而言都是从零开始，而我也是乐在其中。

期间产品两个 iOS 和 Android 平台的版本分别获得了 App Store 以及豌豆荚的推荐和奖励，这在我个人职业生涯中也是莫大的鼓舞很肯定。

产品的迭代用户数量的攀升，带来了团队的壮大以及需求的不断增长，移动团队在公司十分被重视，各种资源都能够得到满足，有段时间内移动端团队相对于其他技术团队独立，这是好事也是坏事就不详细说。

说回到了技术方面，由于没有 QA 团队，所以在质量保证方面产品团员、开发、甚至运营都需要承担一部分的测试和质量保证工作。

“吃自己的狗粮”

这是团队的传统也是为什么不设 QA 这个职位的初衷。现在看来，这个话题还是颇有争议的，或许可以单独开一篇文章去讨论的。

业务的洗礼、QA 角色的“平均”，所以丁香园在技术方面的选型以及步进是偏向于保守的。

不过期间也做出过尝试，令人感到自豪和欣慰的是 iOS 端（2015年）开始逐渐的迁移到 Swift2，在一段时间内由于这块新技术调整造成产品迭代缓慢，产品和需求方都表示理解。

再后面，Android 也想考虑尝试下例如 Kotlin 等技术，比较遗憾我无法参与其中了，这是后话。

业务

写了一半，可能会招惹非议，略过吧。

团队

回到团队本身，如果说总分有十分，我完全毫无保留得给我们的团队打分九分，留一分让我剩下用岁月慢慢给到你们。

我爱这个团队，我爱团队的每个成员，我爱你们。

很多人崇尚的扁平化、足够的自由度，以及“漠视 KPI”，等看起来很美好的关键词，都或许在这个团队都得以实现。

同时，管理层面的 Sense 就是十分关注组员的成长，无论是技术还是个人方面。团队的信息透明也是我所推崇的，所有的信息都不会被二次咀嚼以后，再分别给到团队分别不同的人。

技术方面，能够给予足够的自由度以及尽可能的尝试，这里回过头来思考可能会抛出好几个问题。例如，如何保证团队的自我驱动能力？新技术的尝试如何保证项目本身的质量和进度？等等。

这些我问题坦白讲，我至今也在继续摸索和求证。

很是感谢在丁香园的几年，在管理方面的很多想法都能得到实践以及总结，团队从小到大的过程并不是所有管理者所能亲身经历。

Fenng 曾经和我说或许如果当时留在阿里待遇方面可能会更加可观，我可以很如实的回答，丁香园给予我的这些经历可能留在阿里这些年都无法换回，感谢这六年。

--

2016 年丁香园发生了些不愉快的事情，管理层的变更、团队的调动以及后续管理者的价值观、技术均无法认同，这是我离开团队的根本原因。

从丁香园离职了以后，我也有过抱着巨大的怨念去回忆以及诉说我的离职过程，现在回过头来想其实十分没必要以及幼稚。然而时至今日，还能听到很多或许有关于我以及团队的刺耳言论，个人有时还是无法控制自己的情感。

爱的深，可能就会更在乎它的每个细节。我现在已经可以自我调节和理智面对，对于那些信息的源头的始作俑者，我只想对你们说，你们是永远都不会 GET 和理解我对这个团队的情感以及初心。它对于我而言不仅仅是我一份工作的证明，怎么可能去伤害。

夏虫不可语冰

再见丁香园，曾经和现在都爱过的。

-- EOF --