这是一篇有18年互联网经验、在阿里工作9年的工程师的真实经历和感受，与大家分享，或许读后你能看到一个行业的变化、或许是人生的每一次选择、又或许是每一次的努力与坚持。
2000年也就是千禧年，我从建筑转行到互联网行业，一切都是从头开始，没有互联网的背景，能做的只有大量的学习，但好在我是一个能吃苦的人。
转行的第一家互联网公司是二六三（北京二六三企业通信有限公司），从一个监控人员、客服人员到系统维护，基本上从网络、监控、安全所有涉及到运维的事情我都做过。在最开始，我先从运维做起，那个时候的运维工作门槛较现在来说比较低，但同时也是一个非常苦的活，需要值夜班，在入职第一年的后半年，除了正常的工作时间，经常夜班我也是在的，说是24小时在工作都不为过，不是24小时响应，而是确确实实在机房，在岗位上。
IDC（互联网数据中心Internet Data Center）机房有大量的设备，机器，需要维护，经常有客户打电话说，机器宕机，让帮忙处理一下，“Reset”键我最熟悉 。后来跟客户熟悉一些之后，直接告知密码和账户，再后来，也会有客户打电话咨询问题如何解决。但当时的我，技术不过关，客户的问题也拖不得，只能放下电话，赶紧求助部门的大牛，请教问题如何处理，设备如何配置。当时的我，真是抓住机会就一点点学，一点点抠，不断在实践中摸索，遇到问题就解决问题。
[2002年，是我的另一个转折点，努力才会幸运]
当时的IDC机房基本的收费方式是计价和带宽，后又新增加一个增值业务，就是帮客户代运维，类似应用层的运维，邮箱服务器，监控存储备份等等一系列打包。所以那时我的经理找到我，公司要开展一个新的业务，愿不愿意干，我二话不说答应下来，也不会考虑过多，只是想着，光脚不怕穿鞋的。
当了小组长，就意味着，你要有一定的管理能力，管人和理事。在当时互联网里有一个不成文的规矩，就是谁技术能力强，又肯下功夫，就会有较大概率当选主管。之后我也是花了半年的时间把事情理好，但是管人永远比理事难，管人又成了我的一个难题，最开始不会分派任务。慢慢的我觉得很苦恼，压力也大，我觉得这样不行，我得改变，所以我就想办法，按系统模块划分工作量；给不同的人按照能力，特长分配工作；接着又backup，让大家的工作能够互相cover。所以慢慢的我又学会了管人。
之后我又晋升为主管、到经理，直到总监。到06年初，我就离开了二六三。但是时至今日我仍然很感激在二六三工作的那段时光，给我机会成长。
[机会永远是留给有准备的人]
之后我入职到雅虎(中国），当时全球互联网的态度都在雅虎，在中国是排进前三名的，排在前面的还有新浪、搜狐。
入职之后就发现一个最大的问题就是雅虎经常出故障，但是没人知道有故障发生，所以首要任务就是要检查为什么会经常出故障，排查故障后发现是监控系统缺失，当务之急就是建立一个监控系统。之后又根据实际情况做了一系列的故障流程、变更流程、发布流程等等。我写了能有几百万字，毫不夸张的说，任何一个监控中心，按照我写的流程，都可以解决监控、解决系统、解决报警等一系列问题，写的可能不好看，但是一定是非常实用的。
09年10月，雅虎（中国）进行业务调整，所以整个技术团队，被拆分成三个部分，而我所在的运维就被分到了阿里云。
[人一定要有责任感、要有信念感]
初到阿里云要做云计算，那么架构怎么做？云计算管理不同机型，新旧机器，管理不同算力，这难度异常大，根本行不通。行不通主要有两个原因，一是调度成本非常高，因为要通讯很多不同种类的设备，要了解每一个设备的厂家、型号、批次以及不同设备的运算能力，同时还要快速高效的去计算运行结果，所以这个挑战是很大的。二是从运维角度较难管理，因为我们在云上去申请使用云计算，选CPU，选内存，型号越统一，管理成本越低。除此之外还有监控、存储、安全，和其他一些方面。
当时是有三台主控机，我们就必须考虑如何进行集群管理。一旦master挂掉，那谁来接替管理，这又涉及架构的设计，有很多讲究。对于公共平台来说，最关心的三件事是，数据会不会丢失、数据会不会被偷，第三才是服务器是不是稳定。当然服务器稳定也是客户使用最直观的感受，但相比较来说数据丢失是更重要的事情，因为数据丢失是不可逆的。基于此当初架构设计时考虑有三个副本，加一个轮询机制，在运营过程中，要不断检测副本的数量，一旦发现副本的数量等于二，就立马复制出来一份，就是让系统中永远保持三份。但是最开始轮询周期是很慢的，定好时间发现，时间到了还没轮询完，经常会发生类似的事情。这就是设计的不合理性，跟底层算法有一定关系，设计不合理就会导致效率低。对于我来说，最熟悉的还是架构和运维，虽然说更多的兼容性，是底层的开发工程师做起来的，但是底层的支撑也是更重要的。
[任何一件事情的成功，绝非一个人的努力，一定是团队的力量]
2010年2月4日，负责阿里云的运维工作的负责人组织了一个会议，讨论关于飞天当前RHEL4.7版本的局限性和升级到RHEL5.4的必要性问题，当时作为旁听者我被临时邀请参加了会议。参加会议的有13个人，各部门专家与飞天项目主管。不管是有意还是无意，我接管了这次会议的组织，会议结束后，我也就成了这个项目的PM。
2个小时的会议后的结论是：与会人员一致认同有必要升级到5.4。原因是现在的飞天版本是RHEL4.7，该版本存在安全风险，随着时间的推移，硬件厂商逐渐减少对RHEL4的支持，未来RHEL4的维护成本会逐渐加大。
项目启动，压力也随之而来。对于开发团队来说，需要在一段时间内，面临两个平台的代码兼容性问题！资源方面，升级功能和压力测试，需要一定规模的测试集群该如何提供？时间和业务方面，由于万网要在5月份进行正式的对外生产，因此必须保证在5月份完成万网项目得顺利，因此3月份就需要搞定飞天对 5.4的支持！对于应用的影响，银河，邮件，UC，地图，后羿等等，尚不知道升级到5.4后对他们有什么影响？
启动会议上向大家介绍了项目的背景，目标，并和大家讨论了所需要的资源和我们的升级工作计划。最重要的一项就是给项目取一个好记并且响亮的名字。“五彩石”，就这样诞生了。因为服务的对象是飞天的那些神仙们，存储叫盘古，调度叫伏羲，监控叫神农，通讯叫女娲。还因为都是修补“天”的洞，女娲补的是黎民百姓的“天”,我们是要修补未来用户的“飞天”，女娲补天是要让老百姓过上好日子，我们补飞天是要让未来用户使用的更安全，更舒服。都是时间短，所需要的资源复杂，我们需要动用开发，运维，应用等多个部门，并且只有一个多月的时间就要搞定如此庞大的工程，和女娲补天极其相似。最后，确认项目升级到RHEL5.4，意想不到的谐音，五彩石近似于五点四。
名字有了，接踵而来的就是项目启动时的各种“热闹”。
项目启动后，也受到了大佬和牛人们的重视和回应。承担项目的同时，当时我还在负责雅虎运维和阿里云运维工具开发，运维流程等工作。说实在话，阿里云的运维也正处艰难的开始阶段，启明星项目刚刚进入二期，Clone系统和ODPS如何更好的支持业务，这些难题也摆在了我的面前。但为了保证项目的顺利进行，除了推动相关团队完成既定的计划，还要将进展通知到几乎所有的开发和测试团队。项目日报开始了。回头看看当初每天的日报基本都是在23:00之后发送的，从2月23日开始到4月7日结束，经历了44天，一天没有间断过。
3月3日，凌晨2点，延超传来喜报，飞天的UT测试通过，我特意在当日中红色字体标示，这是在项目正式启动的第11天传来的一个最好的消息！另外后羿支持飞天5.4环境的image将在3月6日完成，预计会在3也9日上线。
3月4日，新的5.4的飞天操作系统的模板确认。
3月10日，5.4OS上的P1的UT，ST测试全部通过，5.4OS上的P1 FT测试，有3个问题，其他全部测试通过。
3月12日 取得了重大进展，集群测试通过，WebUI安装成功，并且通过webUI测试jobs成功，此次测试成功，表明5.4OS版本的飞天应用已经具备可能生产的条件！
终于我们五彩石项目开启了一个具有标志意义的里程碑！！ 此次升级不仅完成我们既定的飞天操作系统从RHEL4.7升级到RHEL5.4的最基本的要求，同时也完成了27集群的升级工作，涉及的服务器近3000台。
“五彩石”的成功，凝聚着每一位的努力与付出。回想起当初项目启动的时候，情景依旧历历在目，也曾彷徨困惑，也曾担心疑虑，但是最终我们达成一致，一定升级，以满足未来高可用云使用的需求。
[ 从运维到业务，我毫不畏惧 ]
阿里金融
12年下半年，我开始做阿里金融的项目：阿里小贷，即贷款给淘宝商家，淘宝在当时号称有“千万商家”。阿里小贷的核心业务就是信誉贷款，信誉是有价值的。
在传统的银行业务领域来说，银行有一套自己的系统以及审核流程，首先银行要审核你的征信，你的房产等一系列信息，审核过程还要十天半个月甚至更久，之后银行才会审批给你相应地贷款额度。相较于传统银行，阿里小贷则用淘宝商家的信誉贷款，商家在淘宝系统上录入的所有信息、数据都是信誉值的构成，包括销售等级、商品属性、交易量和好评率、以及卖家所在的地区等等。不需要任何的人工成本，也不需要冗长复杂的审核手续，直接登录后台，即可查询信誉值，以及申请相应的贷款额度。
我作为阿里云运维的负责人和阿里金融业务的负责人一起，花了大概三个月的时间把阿里小贷所涉及的问题整理清楚。因为涉及到整个数据的拓扑结构，首先就是数据源，数据输入会有不同的输入通道、数据也有不同的类型；又要把这些数据传到飞天硬盘上，使用统一的数据处理，进行统一运算。其次在时间上也有一定要求，头一天截止到十二点的数据，第二天九点就要出结果，这在当时还是有一定难度的。另外，故障也是时常发生。
有问题就要一件件解决，我们从以下几方面查找原因：数据的安全性：当时发现底层开发有一些问题，数据库竟然没有备份，即使我已经有了十几年的运维工作经验，也很难做到临危不乱。一旦出现大的故障，就是大麻烦，之后立马做了备份，而且是不少于两份。第二件事，设计可靠性：一旦写错程序就会报警，改好之后，报警数锐减。第三.开发设计的不合理性：处理数据任务，对job排序，周期长的优先处理，设计最优路径，这样不仅提升效率，也比较稳定。就这样对数据的安全性、可靠性（包括数据关系）、数据的高效性等方面，对数据的采集、清洗、加工、周期等等一系列工序都做了一系列的加工和整改。
ODPS
从阿里金融结束后，我又接触了ODPS (现MaxCompute：是一项大数据计算服务，能提供快速托管的PB级数据仓库解决方案，可以经济并高效的分析处理海量数据) 板块的业务，主要负责ODPS的运行维护和产品的商业化。产品是能使用，而商品就是有一定价值。数据产品的商业化，就涉及到计价和收费。算力如何算、存储如何收费，计算又按什么标准收取费用等等等等。
我们当时服务过客户有：华大基因、中信21世纪（现在的阿里健康）、施耐德等一些大企业。核算下来的数据成本价值还是很高的。
阿里金融云
13年年底，我和我的搭档做了一个项目叫做“聚宝盆”，而且是真正的做了一个产品并且商业化。这个项目的最核心应用是余额宝，当时余额宝的用户是百万级的，但是赶上双十一的时候，要上升到亿级。原本的架构难以承受这么重的任务量，所以迁到云上是势在必行的。直到现在这个项目也仍然还在运营，上面已经有上千家的金融类的企业。
数据中国
2014年阿里有了新的战略目标，数据中国，云计算在中国各地的落地。这个项目的三条主线分别是各省、部委和大企业。当时，我被分到各省的这条线，长江以北的我的主场，第一个落地项目的城市是宁夏，我签了第一个合同，金额达3.3亿。
就这样我做了几个大的项目从阿里云、ODPS、阿里金融到数据中国，我真正的意识到数据是有价值的，数据就等同于金钱。基础设施的不断完备，技术的不断发展，使得数据业务也在爆发式的增长，但同时也带来了性能和成本的挑战。
世界上只有一种真正的英雄主义，那就是在认识生活的真相后依然认真生活。从运维、运营、产品到业务，从建筑到互联网，我不断的选择，不断地突破自己。14年我离开了阿里，开始了做的第一个创业项目，基因检测。18年，我加入了Gravity ，区块链项目。
[写在最后]
人的每次选择都决定了最后生活在哪个平行宇宙，08年1月份，我加入了Gravity 项目，一个真正有了实际需求的区块链项目。
传统的云计算基础设施和高性能的计算操作过于复杂和成本高昂，同时，科学领域以及各行业在运行大型程序和处理大量数据的过程中对计算能力的需求与日俱增，尤其是中小企业也很需要计算能力和数据能力。而Gravity 提供一个共享计算引擎，将空闲的手机、终端、PC 等设备组成一个巨大的计算集群。一种新形式的分布式云计算来实现较低成本的计算。利用区块链价值网络，使资源共享者在互信的网络中获取激励。
区块链是趋势，而我们都将顺势而为。