Wds的技术博客

以下是转自我同事(dorisbhwang)的一片文章，凤凰项目读后感在发此博客前我本人还没有看，但在看了她读后感后更有兴趣来读一读这本书。

---

凤凰涅槃，浴火重生
正文之前，一个职场老司机的困惑…..
作为一个在职场上混迹长达14年的老司机，从制造业的咨询顾问转变为互联网行业运维质量管理人员（QA）,对于我来说可谓是破釜沉舟，从零开始。理想是丰满的，现实是残酷的，投入到具体的运维质量管理工作后，发现我无法再以这么多年沉淀的方法论，以体系化、职业化的姿态来开展工作，尤其是对互联网行业运维体系的生疏，技术上的空白，简直就是致命的…
在困惑无助的瓶颈期，偶然机会运维界男神梁爷推荐看《凤凰项目》这本书，凤凰二字不禁让我想到了凤凰涅磐,浴火重生，自己此时需要的不就是重生吗？既然从零开始，放手一搏，学习吧！
言归正准，此书与各种介绍技术或方法论的书不同，以一个故事的形式讲述了一个IT项目从即将“流产“、IT运维部门面临被拆分的囧境到逐步的通过一系列举措取得项目成功并实现业务价值的过程，浅显易懂，结合自己曾经经历的“难产”的项目（广东电信管线投资管理系统建设项目、HW配置器项目、HW PIA项目），仿佛身临其境，触动了身体上的多根神经，将触动我的几点总结下：

1、  变更管理
提到“变更”，我为之色变，变更无处不在，毫不夸张的说，我曾经被“变更”伤的很深，这是个忧伤的往事，此处省去一万字…首先为愿意正视在变更上存在的问题，并且愿意去为改变这种现状做出努力的管理者或决策者致敬，书中IT运维总裁比尔如是乎，接任总裁一职后，意识到IT变更中的问题，马上对变更流程做了梳理，
采取了如下的措施：
1)  梳理什么是变更，明确变更的范围（这与我想做的工作不谋而合）
附书中定义：变更就是对应用程序、数据库、操作系统、网络或硬件进行的物理、逻辑或虚拟操作，并且这样的操作可能对相关服务产生影响。
2)  执行变更审核流程，加大变更门槛，适当控制变更节奏；
说到这点，不得不提任何流程及工具的推行都会遇到各种阻碍，有些员工乃至管理者甚至可能认为引入流程阻碍了效率，如果再碰到了不好用的工具，那简直炸天了，所以引入流程和推行工具之前必须根据实际情况做深入的调研，多方面平衡，力求流程简化，工作易用，当然这事说起来容易，做起来难，也只能是智者见智了。
3)  变更可视化
做好变更记录，明确变更计划的制定者、变更对象、变更内容;
做好变更计划安排，发布审批通过的变更执行的日程表。
这一点其实没什么好说的，既定的工作如果都不做好安排，随着性子想怎么玩就怎么玩，活该你一天到晚忙到死，还没干成几件事情。
总之，我们避免不了变更，但我们要想办法避免紧急变更。
说到此处，我脑中呈现了一个变更管理的框架：

首先从业务层面要确定变更的痛点，想要如何管理，以上内容不需要面面俱到，可以根据痛点有重点的进行梳理，如果有条件，落地到工具中自然更好。

2、  工作类型梳理
记得我当初刚接手运维部门的QA工作之后，为深入了解运维工作，曾问过几个运维同事的日常工作分类和职责是什么，小伙伴们给的答案居然是含糊不清的，我不知道他们是真的不清楚，还是不善于总结说不出来，抑或是不想告诉我，囧…书中对IT运维部门的工作类型分为：业务项目、IT运维项目、变更及计划外的工作。人的精力是有限的，当各类工作一窝蜂的摆到眼前，谁也不能面面俱到，必要时必须要有取舍，确定不同时期的重心工作，正确的时间做正确的事情。结合实际的工作，身边运维同学对于业务项目和IT运维项目这两类一般能按照项目节奏按部就班的走，但一旦引入了变更和计划外的工作，往往会打乱既定的计划，承诺给业务部门的服务无法完成，所以工作的安排要留一定的buffer，以支持没完没了的变更和计划外的工作（如业务各种突发事件，各类运营系统的bug） 。希望这个工作类型的划分也能够触动身边运维同学的神经。

3、  开发运维模式下的实践
1)标准化
“IT工作不仅是无形的，因此更难追踪，而且可能出错的地方也要多得多。“
因此为了避免出错，需要更严格和守纪律，把运营环境标准化，并把这些标准应用于开发和运维的日常使用。写到这里，情不自禁叹口气，这是我目前的重点工作，曾经为这个目标迷茫过、困惑过，此书看完，坚定了我做运营标准化工作的决心。
2)持续优化
作为质量部过程改进中心的一员，持续优化天然是QA的职责，如何防止问题再次发生，一旦发生了问题如何更快的发现和修复问题，建立完善的问题管理机制的重要性由此可见。
3)营造一种工作文化
鼓励探索和尝试，从失败中吸取教训，反复实践，至于如何落实，我想是团队管理者仁者见仁智者见智了。  

4、  工作约束点
在书中，一个运维工程师是工作约束点，任何工作少了他都无法正常开展…我表示无语，居然会有这样的事发生！在我的经历中，某个人成为工作瓶颈的情况真不多见，不会说少了哪个人天能塌下来。我想团队分工、团队共享和人力储备这些是人员管理的根本吧（纯属个人意见）。 诚然，除了人这个因素，工作中会有各种障碍，反思下我们是否主动识别过约束点，如数据质量差、信息不同步、流程混乱等，识别到之后是否尝试去打破它？至于How，以后再深入学习探讨吧（偷个懒）。

Ok, 到这心得就完了，对于如何继续开展接下来的运营质量工作，我经历了从混沌状态到逐步清晰的过程，可谓是“凤凰浴火，涅槃重生”，路漫漫其修远兮，希望通过我的努力，能够看到质量上的不断的改进和优化，哪怕是一点点。

作者：研究僧
文章地址：http://blog.puppeter.com/read.php?52

项目时间：201603-201608

通常做项目标方向和理想是非常好的，但现实总有这样那样的问题，如以下截图。 所以引出本文在做项目中发现的一些问题：


开篇
      腾讯SNG（社交网络事业群，后简称“SNG”）事业群担负着QQ、Qzone、QQ音乐和相册等核心社交产品运营，从运营的这些产品就能看出部门的历史。笔者没有进入腾讯前在北京工作过多年，记得在2010左右北京的各种IT大会风起云涌当时可以看到各大公司分享自己的架构与运维理念但很少能看见腾讯的分享，当时很纳闷为什么看不到腾讯分享，多年后走进腾讯当年很多疑惑慢慢揭开了神秘的面纱。  
      从架构层级上腾讯和很多公司相同即接入、逻辑和存储但腾讯BG(Bussiness Group 事业群，后简称“BG”)制，外人可以理解BG为腾讯内部子公司，彼此有独立的方向、业务与架构，不同的BG架构不同（接入、逻辑和存储）， 与其他公司不同的是，腾讯在各BG架构上又多了一层“大存储”，这里大存储指各BG数据最终落到统一的BG下，即TEG(技术工程事业群)。以SNG为例接入使用qzhttp（web服务）逻辑之间调用关系用了l5（名字服务），程序开发有spp框架， 数据间传输使用了私有协议，存储使用了MySQL和一些自研的数据存储，可以看到腾讯这里走出了一条有自己特色的道路，它更多使用的是自研组件和私有协议，这也就解释了之前笔者的疑惑为什么很少看见腾讯的分享原因。相比很多公司使用开源组建在基础上做二次开发，但腾讯更多是学习开源组建再开发，区别是后者配置文件些许区别维护学习上有一定成本，但优势更加适合业务使用，足够的轻量级和安全，但问题是业务的需求量有限很多自研组建放慢迭代脚步，甚至停滞迭代为业务发展埋下隐患。
     那为什么腾讯内部的工具不走开源路线呢？ 开源接受的市场更多的需求，需要持续的打磨与迭代， 这问题也是笔者在入职腾讯后一直的疑惑 直到一次公司技术分享A同事的一个问题，A同事大概问的意思是腾讯现在在互联网行业内有一定的影响力与同等公司相比开源做的并不是很好，这是为什么？ 当时公司CTO(首席技术官，英文Chief Technology Officer，即企业内负责技术的最高负责人)张志东是这样回答的。首先对A同事问题的肯定，也介绍了这里的背景，早年腾讯业务爆发式增长工程师更多的精力是应对需求以及当业务发生故障时去救火，再者考虑的就是开源软件对数据安全的问题，如果本身能力未达到应用开源软件后遇到风险不能快速解决结果是致命性的。 这两点笔者身有体会特别是随着互联快速发展，网络安全很重要网各种暴库（csdn 索尼）等事件，做过一个公司的CTO需要更加关注用户数据的安全，这也是我们公司的底线用户安全置上。但Tony也说随着腾讯各个业务步入正轨、技术的沉淀和人才的储备，我们也逐渐考虑去做一开源的工作，鼓励各BG开源。老板的一句话给我们带来更多的思考是如何去开源？ 而开源的前题也是如何更好的使用开源的工具在基础上有机会再开源，所以当时笔者也在想自己的业务上去寻找一些场景适合开源工具的解决方案。

Docker缘
    2014年什么最火，相信很多人会说是Docker ，它诞生于2013年，感觉它的诞生就是一鸣惊人且有不断蔓延趋势，国内很多技术分享也谈了很多Docker的发展趋势应用案例等。2014年底笔者接手了一些长尾业务，由于部门对机器低负载考核比较严格，所以当时也试着将一些高负载业务与低负载业务进行混合部署，混合部署、虚拟化是很多公司解决成本问题的一些手段，像网上经常看到Google很早之前就在用容器技术来实现业务间的混合部署， 当时公司也有很多BG以各种方式实现了不同业务间的混合部署，而由于SNG历史背景的原因很多业务还没有实现混合部署。笔者当时负责系统运营情况，在没有隔离情况下的这种混合部署方案并不好，因为高负载与低负载的业务混部在一起特别是晚高峰期一个大CPU毛刺就会影响到低负载业务从而导致线上投诉，所以在2014底和2015年初借鉴了其他BG的玩法，在部分场景下我们开始通过Docker来实现我们业务间的混合部署，实践证明这种混部要比前者更好，经过2015年一整年系统的开发与迭代初见规模，我们内部称呼为“琥珀离线系统”把高负载业务与低负载业务混部同时，也将高负载业务部署到了部门与公司的Buffer、数据库备机和低负载等资源上，如果业务使用Buffer资源系统，通过建设的系统能力可以将业务请求迅速的从Buffer上调走， 就这样我们把部分业务迁移到了Docker上。
   2015年下半年到2016上半年社交类业务出现了很多转码的需求，转码是用户从PC上传视频通过服务器进行格式与码率的转换在其他终端（ipad，手机）上都能看到，通过我们Docker + Buffer 、低负载形式再次解决了这类业务的需求，为部门解决了大量的成本，Docker离线再一次进入应用的小高峰。
  这时老板们也提出了更高的要求，是否可以实现在线的Docker化，毕竟离线底层用的是Buffer 、低负载资源是有一定天花板的，因为在海量运维中这些资源占比可能连10%都不到，2016年上半年我们开始做在线Docker研究。
   我们做了内部的研究与需求调研，在过程中也经过N轮的PK有人同意有人反对，记得有次一位同事说我们的运营效率可以在分分钟扩容千台机器，什么上Docker？
   答：因为，Docker宣称（Build， Ship and Run Any App， Anywhere!） 它通过镜像串联了开发的整个路径，并保障线上的一致性，你可以把镜像看作App，它可以运行在内部云和公有云上，方便业务以后在各种云上快速的拓展。
   同事：那织云（内部运营系统）在打磨一下也可以实现类似的这功能，为什么还要上Docker？
   答： 额。。。。
   其实当时笔者心里的想法是，是啊其实我们早实现这功能再稍改造就可以，但为什么火的不是腾讯SNG的织云而是Docker呢？ 值得思考。。。
   最终还是决定试探性的来用Docker管理在线服务，Docker这么火而且已经有成功的内部案例，但为什么是试探性这么没底气？
   开篇的时候讲过我们有很重的历史背景，在这种历史背景下没有最牛逼的工具，只有最适合我们的工具，很多创业公司把Docker玩得转因为没有任何历史的包袱，所以这里我们只能说是试探性来玩Docker，看它是否符合业务需求，还有另外还有一些原因：
          1. 刚的对话中已经说明了，内部运营系统早就支持了类似镜像功能，为什么还火的不是织云而是Docker ? 3分产品7分也运营，我想这也是Daocloud（Docker母公司）把Docker当作产品去做，所以这是我们值得学习的。
          2. 很多公司都在搞Docker，当一个新员工入职，你和他说织云，他会问什么是织云，但你说docker很多人会知道，所以不管什么技术，如果他能形成一套“协议”就会让彼此间更好的去沟通。
          3. 内部虚拟化也应用了Kvm，做弹性扩缩容Docker比Kvm更加的轻量级，在社交类业务中镜像有突发流量增长和计算的场景都很适合用Docker。
          4. 部门的运维的质量、效率、成本和安全都做的非常好，如果能以得分衡量应该是98分，但是对追求极致的我们需要的是100分，所以我们要关注开源产品、使用开源产品来寻找自研产品的不足
          5.  笔者曾经看过一篇文章《 为什么要探索宇宙》 文章大意（文章地址见参考）：
          1970年，赞比亚修女 Mary Jucunda 给 Ernst Stuhlinger 博士写了一封信，他因在火星之旅工程中的原创性研究，成为 NASA（美国航空航天局）Marshall 太空航行中心的科学副总监。信中，Mary Jucunda 修女问道：目前地球上还有这么多小孩子吃不上饭，他怎么能舍得为远在火星的项目花费数十亿美元。结论是探索宇宙可以带来相关产业的发展，太空探索就像一面人类审视自己的镜子，利远大于弊。
   相信探索在线Docker与为什么要探索宇宙是一样的，我们他做整个过程当作我们的镜子审视自己系统的不足，并推动改进。

探索在线Docker起航
     从中心下各组抽了一些热心同事，2016年4月份开工在线Docker。 作为运维最不好管控的就是时间前一秒在做项目，突然一个故障立即处理，处理完回过来忘记从哪开始做起刚有头绪又收到新的需求，所以我们需要一套管控手段来保证项目的目标与进度。首先，时间上每个人每天拿出30%来搞项目，其次我们引入了Scrum(敏捷开发框架) 来管理项目， 它的好处就是能在一段时间内，有一个共同目标，大家向着目标不断的跟进持续打磨，信息尽量的彼此间透明，最终保障短期目标与质量。
    前期很多事物在探索阶段整体看Scrum带来的收益还是不错的，我们发现了很多问题，这里有Docker本身问题、还有也有部门运营系统问题低层系统的问题，在线系统上线了300+ 容器运行过程中Docker本身并没有太大的问题。 一个小插曲一台母机上运行了多个容器，其中有的容器是测试机有的容器是在线服务器，某工程师登录测试容器修改了系统时间，由于Docker隔离型不是十分的好，导致整个母机时间都被更改影响各业务，这并不影响在线Docker持续探索，但也提醒我们如果拿整套在线Docker技术方案来做一个产品的化，我们需要一个产品的准入的规则，譬如小明家买了一个洗衣机，洗衣机对小明来说是一个产品，小明并没有看洗衣机的说明说就把衣服放入洗衣机，最终衣服大于洗衣机承载重量导致洗衣机的报废，同样在线Docker也需要一套说明书即准入规则、注意事项、测试过程中发现的问题、案例和潜在风险等，如果超出了准入规则的不准许接如，否则与洗衣机的结局是差不多的。
    运营了一段时间Scrum我们也发现了一些问题， Scrum可以解决一个小团队的问题，但我们需要依赖其他团队时从效率上看就没那么好了，如果Scrum两周为一周期，小团队在一周期内可以解决10件事，而涉及到依赖就只可能解决一件事，因为每个团队有自己的重点及KPI，遇到这种情况Scrum也是无能为力 。

小团队作战
      像Scrum应用中发现他解决不了的问题的案例，在一个大的公司中更多的讲究是团队作战群策群力一个需求来了后对他做需求分析，并拆分需求分给不同团队提升需求的效率和质量。每个部门，每个团队，每个人都是有KPI （关键绩效指标 ，英文全称 “Key Performance Indicator”），KPI的优势是不同环节认同一个目标并持续推进保证收益， 团队与团队之前的协作如果KPI是一致的那事情推进会非常顺利反之只能像Linux进程一样陷入中断状态。
      在这样背景下Scrum可以很好的解决小团队KPI目标、进度、质量，但与其他部门或组交集太多就无能为力了。在线Docker正是这样情况，当你申请其他团队资源时，在KPI的背景下首先被问的目标与收益是否明确，也正因为是探索型项目这些问题很容易被挑战，更多的时间在PK目标与收益。但要知道Google的GFS最初也只有三个人设计开发出来的，所以这种探索型产品前期需尽量少的人参与，与其他团队尽量的解耦 ，短期带来的问题可能是系统的重复建设，长期的收益是整个生态链质量的提升是值得的。笔者也在想Docker离线为什么会成功？ 原因也是开始团队比较小很多问题在内部可以很快的解决，时间上保障项目进度，同时也令大家的成就感更愿意去投入。

设立项目标及流程负责人
    经过一个月的试探，到5月底我们大概掌握了业务Docker在线相关系统的一些问题，解决问题同时也在并行实现Docker在线系统的产品化。 开始讲过参与Docker在线同学来自不同组，结合自己的业务大家从不同的视角希望Docker能带来更多的改善。其实大家的目标是一致的做Docker在线，但过抵达目标的过程却有很多分歧，有分歧是好事做一个产品如果连分歧都不没有就太没成就感了，但此项目就是分歧太多了且都有道理，怎么办？
   解决分歧更好的方式是拿案例来表明自己的想法正确的。PK案例：
   现有流程 ： 测试-> pkg (软件包管理系统) ->预发布 -> 线上系统
   改造流程:  测试机-> pkg ->预发布 （构建镜像机） -> 镜像仓库 -> 线上系统
   旧系统问题：历史原因导致 od未分离，开发可以任意登录线上系统导致系统配置不一致，当预发布环境有问题时，可以任意选择线上机器配置反录入到pkg系统再次发布，相当于给od为分离打了一个补丁。
   改造后流程 ： 预发布构建镜像后，由镜像保持整体链条环境一致性 。但历史原因导致我们的用户（运维/开发）习惯，扩容时是任意选择一台参考机来发布的，分歧就是改造后流程省略了选择这一步，而且首次选预发布机器后为了保障镜像里垃圾信息最少，后续不可以更改预发布机器， 有的同学就会疑问为什么不保持原有习惯？预发布机故障怎么办？ 就这样一个案例PK了多次，最终还是保持改造后的流程方案。
    PK是有必要的，但多次PK就会拉长战线和时间，再加上各种需求就会导致小团队每天很忙接需求，PK需求一段时间过去并没有什么起色，大家对项目的成就感也会打折。Docker在线项目成员来自不同的组，大家一起搞Docker在线形成了虚拟组，其实开始我们就忽略了虚拟组的技术负责，经常出现意见不一致开会PK没有结果再PK浪费时间的情况。有了技术负责人后，它来帮我们屏蔽不合理需求，当遇到问题不断PK时能及时站出给出方向加以解决，保障短期目标，同时提升大家项目中的成就感。
   每天晚上5:00大家都需要碰头沟通Docker在线的进度与问题，有意思的是经过一段时间大家都认为自己负责的环节已经OK了，但整体串联起来就有问题。我们分析了一下原因原来是这样，我们每个人负责的是在线Docker生产链上的一个环节如图1，一个在线Docker包含了多个环节，当自己负责的环节流程1没有问题也就确认自己是没有问题的，结合之前的结果看并没有什么问题。 但成功并仅仅需要自己的成功还要确保自己下游、下游的下游全部成功才可以，所以需要每个人对系统的流程负责，当自己的环节或自己下游环节出现问题需要主动把问题抛出来，同时尽快推进问题的解决。

图1，生产链

用数据来证明
     5-6月底我们通过运营系统在逐步小规模上量验证Docker玩法的可行性，但是随着时间推移发现量并没有快速的上升，原因是资源有限每天在串行的上量，系统的扩容流程一旦发生问题只能停滞待问题解决后再继续。开始感觉经过一段时间量没有上去，没有上去的原因自己也说不清楚，所以当时一直在思考为什么自己也说不清楚，因为流程不稳定错误每天都在发生，每天发生完当时解决完就完了，没有沉淀数据也看不到全局数据能看到哪里的问题比较多。 邮件是一个很好的工具针对这种情况，我们沉淀了所有的日问题数据，并在每周5进行分类汇总，对分类后的结果进行排序，并根据排序的原因设定负责人推进。 经过一段时间数据的沉淀大概能分析出一些问题主要分两类：
1. 运营系统设计的目标和准入标准
     1.1 部门之前一直在提一键运维，从这个目标上看运营系统确实已经达到了，但Docker的扩缩容目标更多的是无人值守运维，目标显然是与目前项目不契合的导致在上量过程中遇到了很多问题。
     1.2 我们运营系统设计过程中的一个重要环节借鉴了Unix设计哲学中的思路，即一切接文件，通过管道来串联文件的输入和输出关系，这也说的是我们运营系统中的流程系统。由于历史原因导致流程系统的环节很长通常扩容一批机器需要16+以上步骤，而流程长就会间接导致成功率的低，从Docker小规模上量过程中期表象更多是运营系统的问题因为他直接暴露给用户，但实际更多是后端错综复杂的逻辑没有接入标准导致流程系统的不稳定。在一个大的系统中需要保证自己成功率的同时，依赖系统也要有严格的准入标准，并通过数据来找出问题，设定责任人并推进优化改善，同时尽量的减少流程环节。
2. 是业务符合架构还是架构符合业务
    笔者时常在思考这个问题，有意思的是笔者在部门中两个角色都做，相信站在不同的角度的答案也是不一样的，笔者之前做过业务所以站在业务的角度希望更多的是架构来符合业务，因为部门负责业务产品比较多每个产品都有快速发展的时候，如果跟不上发展将会被淘汰所以更希望架构来符合业务，实际上从运营系统发展历程上也能看到很多历史的影子 。 而目前笔者从事的是架构，更多希望是业务来符合架构，原因是在实际运营过程中发现运营系统和架构在符合各自产品标准上已经慢慢没有了自己的标准，导致系统臃肿与效率的下降， 另外很多人已经习惯了这种架构符合业务的方式，而最难改变的就是用户习惯，我们能做到的只能是增加架构与业务间彼此沟通，制定架构的准入标准，尽量满足业务的需求，并持续的完善与迭代。这里有一个模式可以借鉴就是微软的windows系列，推翻老的系统不断的更新操作系统的大版本，在实际运营过程中，发现问题再打补丁，同时系统尽量向下兼容，满足客户的需要。

end..

---

参考文章
1）Docker历史　http://www.oschina.net/news/57838/docker-dotcloud
2） 为什么要探索宇宙 https://www.douban.com/note/321442729/
3）Google 全球研发总监访谈 http://news.cnblogs.com/n/542090/

北京工作时在中关村地下广场学的成人钢琴，可惜当时就录制了一个视频。

经常看到网上有人说把一个重要的文件删除了，而恢复成本很高，所以一直在想Linux终端中为什么没有像Windows下的回收站这样的设计，直到看到Unix编程艺术上的一段解释。 其实，Linux世袭了Unix的设计理念与传统，而Unix本身并没有这样的设计并延续到了Linux。

Unix面向更加专业的用户 ,Unix的开发者喜欢清晰、简单的操作，用户告诉做什么就做什么，即便用户使用的命令等价于“向我开枪”的命令。而这样做Unix的开发本能辩解的就是：保护用户避免自我损害，应该是GUI或应用程序级别的事，而非操作系统:)。

这就解释了Linux终端为什么没有类似Windows回收站的设计，当然我们也可以通过Shell方式自己来实现一个类似回收站的功能，以下是笔者在2007年与2008年时写的shell回收站，供参考：
1.第一版本（http://bbs.chinaunix.net/thread-1034672-1-1.html）
2. 第二版本http://m.blog.chinaunix.net/uid-7176662-id-2068124.html）

第二版本原始链接已经找不到了，在网上搜索半天才找到，估计是CU数据迁移时导致丢失，所以为防止再次丢失把版本二贴到本博客一份。

1972 – C语言的先驱——B语言，被贝尔实验室开发。B语言是一个很快速的，容易维护的，而且对于从系统到应用开发是很好用的。设计这门语言的整个团队被马上解雇了，因为他们干了一件和电话通讯不相干的事情。最后这个项目转给了 Dennis Ritchie。他把这个语言变得不容易理解，很难维护，而且，只能用于系统方面的编程。而且，他还设计了一个指针系统，保让每一个程序都超过500行，并可以使用操作系统的指针。

1982 – 大家发现有97% 的C程序调用产生了“缓冲区溢出”问题。于是，C 程序员们开始意识到，就算是不必要也必需要初始化变量。然而，强制性的变量初始化这个明智的决定，很难影响了当时已经写成了的97%的C程序，所以结果什么也没有发生。

1984 – 操作系统出现了“错误指针”的问题数量开始戏剧性地增涨。

1985 – 一系列的让C语言有面向对象能力的解决方法出现了，一个叫“C With Classes”正准备商业化。然而，大家觉得名字“C With Classes”太清楚和容易被理解了，所以，最终的商业版本叫做—— C++。


1986 – C语言成为最流行的语句，其被很多业界分析师推荐于业务应用。他们向全世界宣称——由C语言写成的应用将可以运行在很多不同的平台上的，是跨平台的。目前看来，这些众多的分析者在当时有可能是因为某种迷幻而导致其大脑被所蛊惑了。

1988 – 业界的这些分析家们因为“摇头丸”吃完了。所以，在他们的幻觉过去以后，他们注意到，使用C语言来开发业务应用会增加5倍以上的开发时间，并且程序也不具备可移植性。他们开始停止向大众推荐使用C语言来开发业务应用了，只能很少一部服用可卡因的人开始转向推荐大众使用C++语言写业务应用程序，他们说，“那是面向对象的，所以，代码是很容易重用的”。

1990 – 在这个时候，所有的C编译器都转到了C++编译器上。但是，因为大多数的C++程序员并没有使用C++中那些面向对象的语言特性。也就是说，在实际上来说，那种浮肿的代码结构加上操作系统指针的代码被一种叫面向对象的编译器编译。

1990 – 在雇佣了一些转向“吸胶毒”的分析师后，Sun决定要创造一种叫Oak的语言，这种语言主要用于电视的机顶盒。因为当时几乎所有的程序员的DNA中都有C语的基因，所以，这个语言向C和C++中大量地借鉴了很多它们的语法和编程思路。然而，机顶盒上没有操作系统，也就不存在指针，所以，他们把指针从这门语言里给去掉了。

1994 – Sun公司里的某个人意识到为一个机顶盒开发一个语言是多么愚蠢的事情。于是，这个语言更名为Java，并且为其注入了“Internet”的特征，从而让其成为一个真正可以被移植的语言。其市场营销上相当成功，而那时有3%的业内人士开始明白什么是Internet，同时，那些精神不正常的分析师们还在不停地嗑药并向大众鼓吹他们的神话——“跨平台移植性”。

1995 – Sun 向业界的分析师们提供了免费蘑菇迷魂汤，导致那些分析师在喝下汤后，马上开始写下“Java是一门未来的可移植的和Ineternet高度可集成的语言”。

1996 中 – 17,468,972 篇文章出现，描述了Java是怎么一门未来的语言。这也是Java Applet开始进入Web页的时代。

1996 末– 程序员开始使用Java applet创建他们的Web页面，然后他们开始因为挫折和沮丧开始集体自杀。此时，那些分析师开始增大蘑菇迷魂汤的剂量。

1997 – 因为接受了产生幻觉分析师的建议，Corel 决定重写他们的应用，包括 WordPerfect，当然，是用Java写的。最终的结果是，这是迄今为止比“打字机”还慢的字处理软件。

1998 –  在意识到applet已在快速枯萎，Sun又一次的重新配置了Java，这次，他们叫Severlet，这是一个服务器的程序语言。这个设计在抄袭了Microsoft Transaction Server ，并且，他们说服所有人这个设计是他们创造的。

1999 – 业内那些喝多了的分析师们用一种咆哮的方式向大众介绍了Java 2 Enterprise Edition 。 21,499,512 文章被写出来。但是，实际上并没有人使用，因为J2EE太不成熟，而又太贵了。

2000 – J2EE 最终还是运转起来了（一点点）。而且，所有的Java卖主们开始准备向其砸钱，与此同时，Microsoft 宣布了.NET，这是一个包括了所有的J2EE功能但没那么贵的产品。实际上来说， Microsoft 决定让Windows的用户免费使用.NET 。 Scott McNealy 很愤怒，其对Microsoft开展了相关的法律诉讼。

.NET 包括了最新的C家族语言，叫C#，发音是“C-pound”，继承最家族的传统，使用着一个愚蠢的名字。

2001 – Microsoft 的市场部意识到，在市面上没有人谈论他们的产品，他们找了其中一个程序员一起吃中饭，才发现，他们把C#叫做 “C sharp”。

2002 – C# 成为 Microsoft .NET的一部分。 C++ 的开发者在 Microsoft 平台上为 “managed code”而欢呼雀跃，也就是说，他们最终得到了一个内存自动管理的功能，这一功能正是1991年的Visual Basic 及1995年的Java所创建的 。

copyright (C) 1996-2006 by Billy S. Hollis, originally posted on dotnetmasters.com 13 January 2006