Home | About | English | RSS

  • Feeds

    • 我为什么选择DigitalOcean VPS来做开发

    Jan 6th, 2015 | 2 Comments
    Filed under: container | Tags: , , , ,

    工程师在开发过程中经常需要下载及实时访问国外各种软件及服务，比如从github下载软件及在Linux上运行docker等软件，通常会在本机创建虚拟机或者通过一些公共的测试服务器来进行，我为什么选择付费的DigitalOcean来当做自己的开发环境？ 本文介绍DigitalOcean相对于自建服务器及其他VPS如Linode的优势。

    先说一个案例，一个月前某工程师说，“看了你写的kubernetes文章后，我也打算试下”。最近再碰到他时，他很惭愧的说，“试了好多次，还没跑通”。在国内运行各种常用开发软件确实存在访问国外云服务及各种软件的问题，一方面速度慢，另外也存在不少资源莫名其妙就被墙了，因此更推荐大家使用国外的VPS来进行日常的学习及测试。因此给大家介绍Tim日常使用DigitalOcean(简称DO)的一些便利之处。

    1. 虽然大家所在公司也都有公共测试服务器，但是使用这些资源通常面临多人共同使用的冲突；独占的服务器通常需要领导审批，也存在随时被业务征用走的情况。而在自己工作电脑创建虚拟机则由于占用资源较大，影响本身工作环境效率。使用云主机创建帐号开通一个虚拟机只需要几秒钟，不会出现启动的服务被人停掉的困扰。
    2. DigitalOcean是经过Tim比较后一种性价比非常高的VPS，它的特点是全SSD存储，费用低，比同类型的云服务及VPS如Linode更便宜。按小时计费，基本款每天开24小时只需要1.04元人民币。如果只开1小时，则只收费1小时，不到1毛钱。
    3. 与Linode相比，稳定性基本相当，Tim的博客从Linode迁移到DigitalOcean已经有半年以上，没碰到过稳定性方面问题。
      清华大学的梁斌博士比较了大量VPS之后也称赞digitalocean。

      最近try了很多厂商的vps，一个体会，凡是没有名气的，大多比较渣。而且有个特点，只卖小机器，不卖多cpu，大内存的，很显然小机器好超卖啊。整个vps提供商比较业界良心的也就linode和digital ocean了，他们是把这事当事业在做的。

    4. DigitalOcean支持CoreOS，CoreOS是一种天生为容器而设计的Linux发行版，由于CoreOS没有包管理工具，无法直接安装各种应用，所有的功能推荐用容器来实现，因此可以帮助大家在测试Docker环境时更好理解容器化理念、更好的分清宿主机与容器的边界、更好的理解分布式的容器及服务。DigitalOcean自带了较新版本的CoreOS，利用CoreOS自带的docker，创建虚拟机后1分钟内就可以完成下载镜像及启动容器的工作。
    5. DO的网速很快，可极大提升工作效率，在DigitalOcean美国机房访问github等资源基本上一回车就下载完了，从docker registry拉一个200M的unbutu镜像只要数秒。而国内访问大部分技术资源速度比较慢，比如CoreOS默认是在线安装方式，在国内装CoreOS要2小时以上；从Docker registry下载一个ubuntu image也需要20分钟左右。
    6. 建议使用以下推荐链接 https://www.digitalocean.com/?refcode=b5d7cd2d0410 来注册用户，当你使用及付费后，Tim可以获得一杯咖啡左右的推荐费的好处，你可以获得$10的奖励费用，相当免费使用2个月。

    PS：给那些申请成功的同学：

    1、CoreOS默认的用户名不是你的 ssh-key 指定的用户或 root，而是 core，因此使用以下命令登录。
    ssh -i ssh-key-file core@ip
    2、Droplet在服务器不启动时可能也会收费，如果是测试用途，长时间不用前建议将Droplet删除，以免产生额外费用。

    3、DO美国机房从国内SSH访问会有丢包的情况，可以尝试MOSH来代替SSH，也可以选择新加坡机房。

    4、DO的文档也非常丰富，英文熟练的同学可以参看 tutorials

    一个技术从业人员眼中的2014

    Dec 31st, 2014 | 4 Comments
    Filed under: 随想

    年轻的同学喜欢按学习曲线来看自己过去的每一年，但是这种方式很快就会步入到瓶颈，学习曲线增长突然会变得缓慢。在2013年圣诞节时，Tim还在每天花上10-30分钟玩一款叫Clash of Clans的游戏，并邀请身边的朋友都加入了部落，当时每天的升级成长也很快。但不知道从哪一天开始，发觉升级越来越慢了，需要2周或者更长时间才能将一些对象升级，所以慢慢的对其失去了成就感、耐心与好奇心。

    工程师对于技术的关系也是如此，刚接触第一门编程语言时候，对每一个细节充满了好奇心，发现一种新的语法糖也会兴奋不已。当使用这些技能之后，慢慢的发现工作中只会重复的使用其中20%左右的领域，就这样月复一月的过着。当然学习的习惯还继续保留，工作之外的东西也会去看看其他一些东西，比如花一周学习媒体炒得火热的Swift语言。但较常见的情况是，大家学的这些新潮技术工作中一般不会立即使用，几个月之后Swift怎么写可能一点也不记得了。几次类似经历之后，当再有新的某项技术出来，如果看不到有使用的需要，你已经不打算再学了。毕竟花很大力气学会某项东西，又注定在几个月后会忘记，这种做无用功的感觉很不好。因此最终学习曲线会停滞在某个点。

    前几年在新年来临之际Tim也会去给一些技术媒体投稿，彻夜不眠写出一篇技术圈宏大的总结与展望，希望能给从业人员指出一条明路。但是这种凭借个人视野有感而写出来的东西，最终指导不了自己也指导不了别人。技术领域太广太深，即使图灵奖得主也很难去评论另外一个专业领域未来一年的发展趋势，能看到的各种预测无非是主流媒体的观点汇集而已。于是后来就不写（也不看）这种总结展望了。尽管技术领域内盲从的心理还是非常显著，很需要这种指南类的东西（比“干货”受欢迎多了）。

    在2014年日常感悟比较多的，就是对昨天文章技术团队的标准化与可复用文化所说的技术群体里面的无序感到有些悲观。当一个低级问题，第一次解决时，你会感受到成就；第二次解决时，你感受到责任，第三次解决时，你可能更多的感受到无力。当你观察一个小的团队时时，这些情况不会明显；但当你把目光聚焦在一个稍大的团队，比如50人以上时，这种问题会更容易发现。

    有人倡导自组织团队，包括各级大佬BOSS们也给我们指出这是前进的方向，但是完全具有自组织特征的团队不是很容易见到。Tim身边更多情况是靠各级管理者强有力的执行力去推动。想想如果没有领导的角色可以自运作起来，还是很有挑战的一件事情。当然挑战不包括各种技术大会的那些敏捷教练们。

    开源这个词有些滥用，我个人去评价一个项目时候更多的是看它解决的问题以及带来的价值。国内业界的问题不是开源不够，而是能创造价值的软件太少。单纯去讨论开源运动我觉得和讨论”跑步运动“或者”站立办公“没什么区别，虽然我也尝试站立办公，但是我觉得没必要天天挂在嘴上。

    运营开源最重要的是社区（指贡献你项目代码的群体），先是有了社区，然后有了你的开源project。否则你的项目最多会成为一个带源代码的一款工具软件。经常的误区是一些人觉得将内部的一堆不再维护的代码上传到github上，然后就期望一夜成名，或觉得船到桥头自然直，这就有点naive了。

    虽然大数据很热，但是我认可大部分engineering方向的工程师不适合做大数据这个观点。不是说这些人不够聪明，而是当你已经25岁左右时候，你已经用了3-5年“最好的编程语言”之后，来决定踏入大数据算法这道门，时机有些晚了。大数据的算法是稍微和计算机科学的“科学”二字最搭边的一门学科，这个算法和CS学的那些快速排序算法有很大的区别，通常这些半路进入的engineering类的工程师，最终的天花板可能是一个数据统计工程师或者是协同过滤工程师。即便如此，一代又一代工程类的技术人员义无反顾走了进去，经过半年一年狂热的学习之后，在一些大BOSS不理解的岗位上默默的发挥着作用，并坚信自己已经是迈向金矿的康庄大道上。大部分没有Critical thinking sense的工程师，习惯在因与果之间用“自然而然”推理并联系起来，比如“只要我进一步学好大数据算法，自然而然，就能挖到金矿”。

    2013年元旦时候也写了一篇谈分享、创新与开源，和目前想法也有些明显的区别。

    技术团队的标准化与可复用文化

    Dec 30th, 2014 | 6 Comments
    Filed under: 技术管理 | Tags: ,

    一次某用户在使用系统时候碰到一个问题，但不确认是系统的bug，于是问题通过各级的微博@消息反馈到产品与技术团队。在反馈链中，每一个同事都需要确认一下自己是否也出现这个问题，以便确认是否属实以及问题的范围（你可以理解互联网的从业人员为什么那么忙了）。

    当这个@消息最终传递到当事的工程师手里，他也需将描述的问题再测试一遍，如果不能重现，问题就变得更加复杂，工程师需要从一堆海量的日志去定位当时用户出现这种现象的原因。那一次排查到最后，发现原因是某台服务器的返回的数据不对导致，那台服务器可能是由于在某些特殊情况下，启动了一个不同的版本而导致用户的调用不能正常返回。如果你也是一个工程师，是否有几分熟悉的感觉？

    自从工程师键入第一行代码那一时刻起，开发流程中每个环节都存在出错的可能。比如

    • 代码可能未被单元测试覆盖，当然有更多的团队根本没有编写单元测试的习惯；业务流程未被功能测试覆盖；因此当最终用户才发现不正确的问题时（如文首描述的情况），整个技术团队需要更多的时间去解决。
    • 服务之间的调用方式、参数或逻辑不正确；当服务由不同的团队维护时，出错的概率会更大；另外一个团队的服务往往只有几行文字的描述的邮件，很多参数语焉不详，你需要通过以前的代码或者亲自调用一下来推测这些参数的作用。这时候如果你需要的功能刚好能调通，欢呼之外就是接着提交及发布代码了，因为上面已经开始对你联调时间过长有些不满。
    • 发布的版本、配置、顺序、服务器等不正确。尽管大家都觉得有一个上线手册之类的指导文档，但在实际工作中开发与运维的交互可能会是通过IM工具，开发工程师说，今天上线模块的顺序是ABDC，运维工程师虽然对为什么不是ABCD的这样的顺序有些疑惑，但也依照开发的顺序做完了。而下一次上线前，开发工程师没提及上线顺序，运维工程师可能纳闷，到底是ABCD还是ABDC呢？

    上面种种情况，如果每一次代码修改及发布都依赖每一位工程师的细心及考虑周全的话，则高概率的质量问题不可避免。而工程师则很沮丧的发现经常在解决同一类型的问题。而将全流程更多不易变的单元编程标准化，由程序来控制，则可以从源头上减少问题，让软件开发变得简单及享受。在上面例子中，可以将（1）测试过程标准化。（2）在服务化架构中，将更多的单元标准化。（3）发布流程标准化。这些点更多的看各团队工程的成熟程度。团队中标准化程度越高，软件的可靠性就会越好，更多的精力将会从各种不确定性问题中解放出来。

    说下第2点服务标准化的一个例子，Tim所在团队最近几年做的系统密集的使用了消息队列，经过几年的演进，也将各种很复杂的场景实现在系统内，比如多级串联、并联、实时性要求非常高的PUB/SUB，用自定义各种服务池来做任务调度，踩了很多坑也积累了很多经验。但是标准化意识以及抽象能力不足，业务架构与技术架构也缺少分开去考虑，因此大部分系统主要针对自己特定场景的设计去实现，即使有很多有价值的特性，但无法复用到另外的场合。当一些新人去学习Kafka这些系统时，老的架构师也会去反思标准化的问题。当然，3年以上的技术团队才会有这些感悟，年轻的团队通常会沉浸在搭建自己系统的快感中。

    再说另外一个例子，曾经有一篇技术贴说某个美国的工程师Twitter技术面试失败的经历。

    然后我们聊了一小会关于在twitter的生活。
    我挂掉电话的那一秒我意识到了我的答案是错的。
    ……
    现在我扪心自问：在这件事我学到了什么？客观地说——不多。对于面试官没有问我正确的问题来引导我向正确的方向思考，我很难过。当我的解答实际上不正确的时候，我不知道为什么Justin告诉我“这应该有用”。

    从中可以部分感受到硅谷科技公司对工程师的严格要求。但是国内的情况有所区别，由于互联网行业有些过热，合格的人才处于供不应求的情况，因此大部分岗位要求都比上文中描述的要求低。工程师只要具备基本的学习及模仿能力，比如能参考一个现有的软件能够实现相同的功能，那这个工程师基本能进入各个互联网技术岗位（当然表面的工作经历也是需要的）。

    在这种情况下，整个技术群体很难对代码质量形成太多共识。再加上大多团队是业务驱动型（技术驱动的凤毛麟角），企业对于技术的要求局限在按时交付。精心雕琢的软件相比于打补丁修补而成的软件并不会得到更好的价值体现，因此追求高质量软件的风气也不易形成。

    企业里面的软件可复用还有恶性循环的情况，比如某个工程师做了一个公共组件来解决一些公共问题，但是另外一个团队在使用后发现存在一些问题，理想的情况是，反馈的问题得到了及时修复，解决了各个团队共性的需求，公共组件在更多场合得到了推广。但在现实中，具备开发良好公共组件能力的人是非常稀缺的，尽管每个Web开发团队都有开发一套自己的MVC框架，但在做到优雅的业务实现方面尚有不足的情况下，一厢情愿的去做自己的标准组件是较难把握共性的需求及得到使用认可。

    在另外一方面，其他的团队也容易把“那个版本没有很好的满足我们需求”的情况成了自起炉灶的理由，通过各自建设，表面上完成了自己的内部需求，自认为团队内部的认知成本是降低了，但人的精力毕竟有限的，有限的时间只能做好有限的事情，最终各自搭建可能也只能建成一些不可复用的系统，除了短期的自我充实感之外较难有更多的价值。