这篇文章充斥着大量的个人回忆，错漏难免，没有深度、没有干货，请看官见谅。

当我们讨论游戏程序的时候我们在讨论什么？​

• 游戏应用——Game Application，手机上直接运行的游戏，比如：Invasion、Brutal Age
• 人——Programmer，把游戏制作人策划的想法和各种资源整合起来，实现成能在设备上运行的游戏应用的人

话说自上古时代 Computer 发明以来，越来越多的工作需要用 Computer 才能完成。有那么一群想在上班时间摸鱼的人对不能用 Computer 摸鱼表示强烈不满，甚至扬言如果 Computer 不能摸鱼还要它何用，不如卖了换钱。有一群善良的 Programmers 听到了上帝的召唤：“要能摸鱼！”，于是就有了世界上第一批 Game Programmers。

SRE 方法论​

确保长期关注研发工作​

Google 将 SRE 团队的运维工作限制在 50%以内。

SRE 处理运维工作的一项准则是：在每 8-12 小时的 on-call 轮值期间最多只处理两个紧急事件。

所有的产品事故都应该有对应的事后总结，无论有没有触发报警。事后总结应该包括以下内容：事故发生、发现、解决的全过程，事故的根本原因，预防或者优化的解决方案。事后总结的目标是尽早发现和堵住漏洞，而不是通过流程去绕过和掩盖它们。

在保障服务 SLO 的前提下最大化迭代速度​

一般来说，任何软件系统都不应该一味地追求 100%可靠 正确的可靠性目标，必须考虑以下几个方面：

• 基于用户的使用习惯，服务器可靠性要达到什么程度用户才会满意？
• 如果这项服务的可靠性程度不够，用户是否有其他的替代选择？
• 服务的可靠程度是否会影响用户对这项服务的使用模式？

Docker 项目的目标是实现轻量级的操作系统虚拟化解决方案。

Docker 的基础是 Linux 容器（LXC）等技术。

在 LXC 的基础上 Docker 进行了进一步的封装，让用户不需要去关心容器的管理，使得操作更为简便。用户操作 Docker 的容器就像操作一个快速轻量级的虚拟机一样简单。

首先，Docker 容器的启动可以在秒级实现，这相比传统的虚拟机方式要快得多。 其次，Docker 对系统资源的利用率很高，一台主机上可以同时运行数千个 Docker 容器。

开发者可以使用一个标准的镜像来构建一套开发容器，开发完成之后，运维人员可以直接使用这个容器来部署代码。

应聘​

• 招聘应聘的重点是在于双方需求的匹配
• 了解清楚招聘方的需求————需要什么样技能的人、额外要求的能力还有什么，自己是否能满足这些要求
• 想清楚自己的需求————想在这份工作中得到什么

简历注意事项​

• 不要所有公司、岗位都用同样的简历。了解投递的岗位，简历上针对性的选择重点。
• 简历一定要突出重点，不用大而全

• Focus on one major idea.

• Give people a reason to care.

• Build your idea with familiar concepts.

• Make your idea worth sharing.

• 长达 25 年的经验教训一：快速发布，短发布周期很重要
• 长达 25 年的经验教训二：流程的扩展性需要分布式层级状的开发模式，全靠 Linus 一个会死人，职责分工明确才能提高效率
• 长达 25 年的经验教训三：工具很重要，迁移到 BitKeeper 颠覆性的改善了工作方式，而至 Git 的迁移则进一步提升了工作效率
• 长达 25 年的经验教训四：认同性原则很重要。若某个改动有一个有经验受尊敬的开发者反对，那么便不会合并。这保证了不会有任何变动会以牺牲某个用户群体为代价。
• 长达 25 年的经验教训五：没有 Regression 原则很重要。尽管偶尔实践的不完美，但是保证了用户不会为内核升级而特别担忧。

简介​

• 功夫小子是一款多人格斗竞技游戏，无成长，游戏中可切换武器，强调武器平衡及个人技术
• 开发：盛大成都研发
• 运营：盛大上海（后转入成都锦天）
• 上线时间：2007 年
• 运营状态：alive
• 盈利模式：免费卖道具的方式，主营是武器。由于一开始就卖了永久的武器，所以后来都不做限时武器了，全部是永久的。
• 最高时做到过盛大全公司收入前十

相对的动静两条线

静为骨架​

目标​

这个是最最重要的，但往往被忽略或者传达不清晰

节点​

很好理解，就是啥时候要

充分授权​

理想的项目管理应该只跟结果，不在乎过程，因此应该充分信任执行人。这一点看不懂技术的反倒适合。

动为血肉直接影响执行力​

需求变更管理​

消费者产品这一点很重要，互联网产品能做到很不错的需求变更管理，如果传统行业也能提速，是否会有颠覆？

资源调配​

项目管理角度来看可能是几个小组之间的协调，执行人来看可能是任务优先级的变更，往往和需求变更有很大关系。

需求不变的项目不多见，对项目管理要求就低的多。

是否需要每天向执行人了解进度情况​

基于充分授权的思路应该是不用，只需要在节点前适当了解即可。然而出于某些不信任（其实不应该有不信任，管理者不信任）因素或者资源需求经常变化的项目可能需要经常了解。

我的电脑还没连网，也想过要和 Internet 连上。据说，网上黄毒泛滥，还有些反动的东西在传播，这些说法把我吓住了。前些时候有人建议对网络加以限制，我很赞成。说实在的，哪能容许信息自由的传播。但假如我对这件事还有点了解，我要说：除了一剪子剪掉，没有什么限制的方法。那东西太快，太邪门了。现代社会信息爆炸，想要审查太困难，不如禁止方便。假如我作生意，或者搞科技，没有网络会有些困难。但我何必为商人、工程师们操心？在信息高速网上，海量的信息在流动。但是我，一个爬格子的，不知道它们也能行。所以，把 Internet 剪掉罢，省得我听了心烦。

今天和同事谈到，到底是产品重要，还是营销重要。同事引用了木桶理论，认为哪个都不能缺，哪块板短了都不行。但我认为，产品不是木板，那是桶底啊！桶底是漏的，其他木板再长有什么用？