架构师的成长之路

• 全球架构师峰会
• 中国系统架构师大会
• 又拍云技术委员会实施细则

在英国，至少要需要学习七年才能成为一名合格的建筑师，要保证合理和安全，并因此承担法律意义上的一切后果，在软件领域中的架构师却流于形式，架构草率在错误中前进，太随心所欲而且没有任何负担。

做架构的首先是去验证这个架构是不是合理，是不是满足需要；这个是道，是战略。如果架构都不合适了，那你怎么搞都是偏离了方向。

然后再去找相应的工具来实施。至于你用什么工具，这个是器，从战术的角度去考虑如果在单点上提高。

架构师掌握的解决问题的方法，或者是思维方式，并不是具体的解决实现。

随着互联网时代来，世界的联系变得越来越紧密，越来越快，新的机遇和挑战也伴随而来

• 如何成为优秀的运维架构师
• Velocity Web 性能与运维大会

• 系统管理员
• 网络管理员

• 谷歌、苹果开发者大会
• 百度、腾讯、阿里云开发者大会
• Qconf全球软件开发者大会、中国软件开发者大会

• 前端工程师
• 后端工程师

性能四大杀手（数据拷贝，内存分配，上下文切换，锁机制）

• 中国互联网运营大会IOconf
• 中国运营支撑大会(CBC)

• 产品经理
• 技术支持
• 销售客服

我更喜欢称运维工程师为： 基础/底层工程师/架构师

运维工程师的主要工作是

1. 精通操作系统
2. 精通网络
3. 精通各种系统软件部署和配置: 数据库，nginx，haproxy，redis…及业务软件
4. 精通各种监控，指标优化，自动化部署

运维工程师的挑战(快，准)：

限时拆弹，随机应变，运筹帷幄

• 运维工程师 = 冲锋陷阵的将军
• 软件工程师 = 坐阵帐中的军师

所以要能够打胜仗，离开谁都是不行的，但“将在外，皇命有所不受”，运在现场随机应变是非常重要的

理论上，优秀的软件工程师是可以把部分/甚至全部运维工程师的工作做掉，比如说业务软件性能的监控，如果程序员在程序中插入很多的钩子或探针，就可以统计出数据来，不需要运维费心监控；

比如说程序员在设计程序的时候，考虑到了分库分表，考虑到了大并发和分布式的设计，那运维就可以水平扩展机器就行；

如果。。。还很多如果。。。但是，现实是残酷的，这种高水平的程序员太少了，再加上精通系统的全面发展的程序员，在中国就更少了。

举个例子，我们可以看看开源的成熟软件，光是程序日志信息非常详尽，我们可以通过标准的syslog或者日志去监控它，但在我接触到所有的公司和程序员中，大家都忙于实现业务功能，连个文档甚至注释都不愿意写，更提能够考虑这么周全了，所以

运维工程师其实是现实中的软件工程师的互补，因为大家的能力侧重点不同，所以大家是团结一体的

1. 产品
2. 网络
3. 系统
4. CDN

• 自动化工具集（正确的文件→正确的地方→正确的权限）
• 服务器配置的标识和统
• NFS共享目录 + 定制脚本

• 配置自动化分发（ansible + playbook）
• 故障处理

• 系统资源监控
• 服务运行监控
• 性能分析报表
• 日志集中分析和处理

• 目标职位：架构师
• 目标内容：做个懂业务、运营、运维的软件工程师（信息量大，够喝一壶了）

技术领域：

• 闲下来：精通三剑客（75年）编程；rpm/puppet自动化部署，节省时间和精力；关注新技术，了解和掌握，至研究，做好铺垫
• 走出去：学着3P编程，至少精通一门编程语言，能够打通前后端的最好，如Python,Ruby;喜欢后端的可以是erlang/go,前端可以是js/php/Nodejs
• 多动手：技术是个竞技项目，无论是否有天分，都要勤加练习，熟而巧，巧而精，因为运维是个限时拆弹的高压工作，速度与激情的结合

非技术领域

• 多看书：看书很重要，查漏补缺，技术书和情商的书都要看，可以文艺，但不要抱怨，懂得感恩和回馈，心明见性（十年学佛小结）；
• 常思考：多做笔记，温故而知新，修订完善（WiKi）；学思结合，学而不思则罔，思而不学则怠；信息多？长知识？生智慧？要学会沉淀，举一反三
• 心态正：正确理解牛人的内涵，任何人都有可以学习的本领，关键是你的心态
• 乐分享：尝试发表文章练文笔，或翻译英文的最新资料尽多参加甚至组织开源活动，锻炼自己的口才和交际能力，经营好自己的影响力，可以交到更多的朋友

上述观点都是告诉大家，如何修炼内功，其实我更强调团队协助，其实个人英雄和团队协作并不矛盾:

• 内修提升能力，外练结朋交友，两手准备，脚踏实地；
• 戒骄戒躁，谦虚进取，每天进步一点点，今天比昨天更好；
• 能力决定高度，细节决定成败，成功总是眷顾有准备的人

人生本来就是一场苦修行，事实是，世界上没有哪个工作不辛苦，何工作都有自己的特点，美国总统（棱镜门事件）不也有苦逼的时候？关键是心境。

微博上有一个定义特别恰当：

苦逼工种的定义：即不能参与决定，也不掌握生产资源，却要对整个事情的结果负责。

但我认为这里包括二个意思：
苦：

运维工程师要和笨重冰冷的机器，喧嚣的机房，复杂的网络及坑爹的南北互，莫名的网络故障或者攻击作斗争，对技能和体能要求都很高，这是事实。或许，我们可以这样理解：

1. 如果你对这些硬件有感觉，就要培养兴趣，就会爱上机器，找个理由让自己快乐起来，这样就可以苦中作乐；
2. 其实上架布线并不是经常的活，换个思路就当是健身锻炼，练练肌肉；如果是经常的事，那就要运维自动化了；
3. 专业的事交给专业的人或机构做，如硬件采购，测试，成品线等等，尽量减少细小琐事所带来的耗；

相信自己，相信队友，爱上运维，那就坦然接受挑战，就这么简单。
逼：

我理解的“逼”就是“逼迫，背黑锅”的意思，这个问题就不是一二句能够说清楚，有团队自身的原因，也有上层对运维工作不理解的因素。我一向反对因为工种的不同而区别对待，其实一流的运维工程师并不比三流的程员甚至架构师差，关键是团队协作，责任分明。

魏文王曾求教于名医扁鹊：“你们家兄弟三人，都精于医术，谁是医术最好的呢？”扁鹊：“大哥最好，二哥差些，我是三人中最差的一个。”

扁鹊解释说：“大哥治病，是在病情发作之前，那时候病人自己还不觉得有病，但大哥就下药铲除了病根，使他的医术难以被人认可，所以没有名气，只是在我们家中被推崇备至。我的二哥治病，是在病初起之时，症状尚不十分明显，病人也没有觉得痛苦，二哥就能药到病除，使乡里人都认为二哥只是治小病很灵。我治病，都是在病情十分严重之时，病人痛苦万分，病人家属心急如焚。此时，他们看到我在经脉上穿刺，用针放血，或在患处敷以毒药以毒攻毒，或动大手术直指病灶，使重病人病情得到缓解或很快治愈，所以我名闻天下。”魏王大悟。 　　

事后控制不如事中控制，事中控制不如事前控制，可惜大多数的事业经营者均未能体会到这一点，等到错误的决策造成了重大的损失才寻求弥补。弥补得好，当然是声名鹊起，但更多的时候是亡羊补牢，为时已晚。

1. 先检讨运维有哪些不足：运维能力的高低决定话语权，能力强自然就能够参与决定，就可以申请资源；
2. 更重要的是，对上层来说，谁有证据，谁就有发言权，所以运维在提升自身能力的同时，也要用好监控数据这个法宝，包括性能指标，业务指标，通过数据不光能快速定位程序问题，也能防患于未燃；
3. 有时候还要把专业数据转化成报表(BI)，能够用上层更容易看得明白，听得懂的故事去表达，争取资源；
4. 积极参与事前的规划，配合程序做演练，架构改进
5. 合理提需求，要资源，最好是有预算，做到防患于未
6. 线上监控，故障分析，反馈给整个团队，倒逼上下协调做改进

因此，劳其筋骨只是工作中的一种锻炼，承上启下，协调团队才能不让自己被“逼宫”，当然，要达到上述要求的运维团队，肯定需要潜心静下来，任劳任怨的修行几年，一蹴而就肯定是不可能的。到那个时候，运维就不再是对事情的结果负责，而是转变角色，主导和协调整个过程，当然，这里指的能力不仅仅是技能，还包括对业务的理解能力，站在公司管理层面对整个项目和资源的分配和把握。（这个修炼过程后面再解）

下面以我的经验，谈点个人看法，全面的认知这个误区。我们以全球架构师峰会为例，架构师是所有IT人向往的殿堂，但架构师的职能包括：

• 基础底层架构师（组成人群：运维工程师）
• 软件开发架构师（组成人群：件工程师）
• 业务运营架构师（组成人群：销售，市场，COO，CEO）

这里我们可以把运维工程师重新定义一下： 基础/底层工程师/架构师，这样听起来会不会更加诱人点。

运维工程师的主要工作是要精通操作系统，精通网络，精通各种系统软件和业务软件的部署，精通监控和精通优化。。。

大家有没有发现，其实说白了，所有本质都是软件，这一点我们必须承认。这就是为什么软件架构师听起来更牛B，因为人家是创造软件，运维工程师是现场运营软件，那为什么还需要运维工程师呢？ 因为像操作系统linux，数据库mysql/postgresql，再如久经考验的如nginx,apache,squid,haproxy,lvs,zabbix,sphinx,hadoop,mongodb ….一般做上层应用的公司是不会重复制造轮子的，它们要集中精力做好应用业务。所以，就需要有人去精通这些系统和软件，能够玩转和调优这些软件，保证底层系统的稳和高效，这就是运维工程师的价值（你可以想像成运维工程师更像是冲锋陷阵的将军，软件工程师就像坐阵帐中的军师，所以就岗位而说，要能够打胜仗，离开谁都是不行的，“将在外，皇命有所不受”，这就是为什么在现场随机应变是非常重要的，运维就是线上命脉的保证，同样非常重要）。

理论上，软件架构师是可以把部分/甚至全部 运维工程师的工作做掉；

1. 如果说业务软件性能的监控，如果程序员在程序中插入很多的钩子或探针，就可以统计出数据来，不需要运维费心监控；
2. 如果说程序员在设计程序的候，考虑到了分库分表，考虑到了大并发和分布式的设计，那运维就可以水平扩展机器就行；
3. 如果说程序在运行过程中，提供了start/stop/restart的逻辑处理，运维就可以放心维护；

如果。。。还有很多如果。。。但是， 现实是残酷的，这样的程序员太少了，在中国就更少了，大家可以看看开源的软件，但凡名大的，程序日志信息非常详尽，我们可以通过标准的syslog或者日志去监控它，但在我接触到所有的公司和程序员中，大家都忙于实现业务功能，连个文档甚至注释都不愿意写，更别提能够考虑这么周全了，所以，看不起运维工程师的软件工程师，想请他自省一下，自己是不是达到这样的水平，能够帮助运维排忧解难，如果不行，那就请尊重运维工程师，因为大家的能力侧重点不同，所以大家是团结一体的。

关于云的解惑，云毕竟是先进的发展趋势，但不必太担心，未来的云还是以公有云和私有云并存的局面，一些小运维角色的确会消失，但在私有云上，还是需要相关人员的。这也对运维人员提出了更高的挑战，所以，以前运维要熟悉各种操作系统，各种系统软件的应用，就要转变思路，要熟悉各种云操作系统，云组件的应用。

最后，我仍然要不断强调的一个观点：

架构师它可能不是一个人的角色，而是一个团队的统称，它可以

• 不必冲锋陷阵，就可以纵观全局，运筹帷幄，调度所有的资源（运维架构师的功能）
• 可以带领和团结团队，高屋筑瓴，因时制宜的实现解决方案（软件架构师的功能）
• 可以把握公司业务方向和深度，洽谈合作，控制成本（业务架构师的功能）

随着时间的推移，每一类型的架构师都是可以从上述一个个岗位中成长起来的，比尔盖茨最初也要亲自码代码，李开复最初也要组建和带领google中国团队，所以，没有从天而降的天才，只有一步一个脚印的磨炼才有们现在的成就（认清自己不是天才，就算是天才也要努力），我们现在要做的就是一方面内修本领，提升自身能力，另一方面外联志朋，寻找身边可以互补的志同道合的人，共同迎机遇和挑战。

莫过于在每一次的工作经历中，哪怕我离职了，因为我的真诚踏实，过去的Boss都愿意继续跟我做朋友，保持良好的沟通。

主要原因是我在运维方面的理念和方法：

1. 我始终强调工作内容的标准化、流程化、自动化，这样可以降低对特定人员的依赖，节省了专业人员宝贵的时间和精力，这样才能有更多的时间去学习新的知识和提升；
2. 建立完善的IT流程的文档管理，无论是设计，实施，后续维护甚至是新技术的研究项目，都有详细的WIKI记录，方便不断的修订改进，这也为公司的持续发展和创新提供了可靠的依据；

好处是公司不会因为运维的单点故障，而影响正常的工作效率；每个人节省下来的更多时间和精力来提升自己，自然也不会是公司的天花板。

于是有些人会想,那饭碗怎么办呢? 我的回答是: 与其担心饭碗不保,不如用心做好事情,让更多更好的饭碗来找你。我走是因为我需要更好的发展，这很正常，同时我也希望我的心血能够在公司里继续发扬光大，这也很正常，所以这两者并不冲突，关键是你的心态。

最后给个建议，不管我们做什么，任何人都不应该成为公司的单点，不要以为这样就洋洋得意，这其实会把你推到火坑里，如果是这样，就诚恳的跟老板说说你的担忧。最后一句良言，万事先修德，做事先做人，一定要重视自己的信用和交际圈，这会给你带来好运。