看着一个个“庆祝3000万”的运营推广活动，心里却没有一丁点儿的兴奋，反而成为了失落感的起始点。
一个“3000万”的背后隐藏着一大堆冰冷的数字：100+台（平均84GB内存+16C）服务器（物理机+虚拟机）、50+个应用服务、300+个Redis实例、500+个应用进程、10W+高峰并发、8亿+日API访问量、每天1TB+系统日志......，看起来我是在装逼的节奏。
看得见的是数字，看不见的是真相
如果系统是一个偏查询类的应用，我想几个号称10W并发的Redis实例足以支撑千万级用户+10W并发规模的系统，你还会觉得NB吗？如果1TB的系统日志有50%是非主动业务触发，并且可能只有0.1%的日志才具有分析价值的系统，你还会觉得NB吗？如果3000万用户里面有99.99%的用户是“被迫”使用的，你还会觉得NB吗......
纵观数年，最兴奋的莫过于当年几个同事守在服务器前7*7*24小时不间断地寻找问题和重启服务服务器，往往最花费时间的事情就是大海捞针，而这一根“针”也往往就是一行代码或一个配置的事情，也是对这跟“针”的发现让我的程序员生涯兴奋指数登上了高峰。这种程序员的“单纯”，我想只有程序员才能懂。作为程序员，“高性能、高可用、高灵活”是我的目标，作为管理者，“政治性、社会性、经济性”是我考虑的重中之重（考虑因素权重排名分先后顺序）。我喜欢并擅长把一件复杂的事情简单化，但有时候不得不面对必须把一件简单的事情复杂化的现实存在。程序员时期面向的都是正向挑战，而当下面对的更多是一堆不情愿的负向情绪。
今天的数字，其实只是延期了四年的结果
按目前的资源规模，别说3000W，再多的用户量都能支撑，这份自信心源于4年前对架构整改方案的决策。不知当年哪来的勇气，拍着自己脑袋喊着“自主研发”。可能是那一周连续的故障排查把脑袋短路的原因，埋下了“控制”的欲望。近千行核心代码的自主框架实现了高约束和规范的IOC和AOP，抛弃对各种外部中间件的高度依赖（如会话管理、数据分布式方案等），让系统建设的主动性和可控性完全掌握在自己手里。无论从8台服务器扩展到目前的100台服务器，还是从5个服务扩展至50个服务，亦或从单一局域网到混合私有云的迁移，这一切的顺利归功于当年对系统可控性改造和持续性建设的执着，回想起这些“前瞻性”的决定，确实有时会感到那丁点儿的自豪。
我不能保证99.99%的稳定性，但......
系统有Bug很正常，运维操作失误也是常有的事，系统上线出错回滚更不在话下，所以我不敢保证系统100%的正常运转。通过对故障的“大数据”分析，我们系统的故障率（所有大小故障）大概30%，也就是三天一“日经”，所以我无法保证4个9的稳定性。但通过数据显示，故障的99.99%都不是我们系统的内部故障，而是对接外部系统的故障。无论我们系统容灾能力多么强大，“系统繁忙，请稍后再试”成了我们唯一最有价值的降级方案。有些许朋友经常向我反馈，为什么你们应用经常“系统繁忙”，我会很自豪地跟他们说：“幸好是我们做的，换作别人，给你个白屏，连‘系统繁忙’都不跟你说一声”。
有时候一个“满意”的回馈比这些数字暖和得多
目前同时掌管着大数十号人以及多个项目，无论如何，整个组织的顺利运转还是归功于以上多年方法的思考以及工具的积累，但最让我舒心的不是以上系统用户量的突破，而是其它小规模“自主应用”给用户体验所带来满意的回馈。一串串大数据的背后可能是一个个冰冷的KPI指标，但一个个用户的认可却是真金白银的服务回馈。或许，以上的这些感想只是因为人生阶段的不同对满足的追求有了不一样的想法而已。
