运维就是一场没有硝烟的战争

最近在优酷上在线看了老男孩的“如何撰写优秀系统运维架构解决方案及推动实施案例分享”(一场没有硝烟的战争)的视频，非常有感触。随着业务和应用的发展，公司的IT架构和系统运维架构都是需要不断进行调整的，而作为运维人员在确保线上稳定的情况下还需要不断去深挖系统架构中存在的不足和潜在的问题，而系统架构的调整通常会面临风险，从这个角度上说运维就是一场没有硝烟的战争，这场战争背负着运维人员的价值和企业IT的自身发展和跨越。

一、运维人员的成长与价值

引用老男孩的一段话“在企业的实际工作中，大多数朋友在遇到工作中的架构、系统等等问题或缺陷时，起初都会主动和领导说，我们的系统，架构有什么什么问题，但是你和领导说完话后，领导经常会一笑置之，或者不以为然，杳无音信，甚至给你泼一盆冷水。你的积极主动的心态就这样日复一日的被磨平，加薪升职的机会也就变得遥远甚至无望。如果遇到比较好的领导，则会指引你，例如：让你写解决方案，并用数据说话，你可能苦于不会写方案或者撰写的方案太烂，导致最终没能达到推进改进工作中问题的目的，也因此错失了提升自己技能和发展的机会。”

他的这段话道出了大部分企业或公司里的现状，运维或IT人员通常被领导看做专业服务人员，IT部或运维部也通常被认为是成本部门而不是创造价值的部门，你做好是应该的，而出了问题就是你的责任，所以大部分运维人员提出的问题或系统缺陷不能引起领导的重视。但是作为一个运维人员，只知道按部就班的处理问题和解决故障，在企业里是很难得到重视和加薪升职的。

如果你要成为一个积极主动的优秀的运维工程师，就需要在完成本职工作的同时还能自己主动去研究一些问题，发现系统架构中的缺陷和不足，并最大限度的实现改进公司系统架构等问题，从而才能体现自身的创造工作价值，从而加快自身成长及获得提升的空间。

二、方案的撰写和演讲能力的培养

很多运维工程师包括技术很牛的运维工程师，处理问题和解决故障很有能力和水平，但是却写不出一份优秀的技术方案，结果不能数据说话，也不能被领导了解和信服，这样无形中错失了很多表现和提升自己的机会；再或者遇到架构、系统等方面的问题或缺陷，自己知道但也不能写出一份优秀的解决方案，最后没能得到大家的认可，自己提出的建议没能被公司采纳并实施，自己也觉得很郁闷，久而久之失去了激情和创新的勇气。

老男孩在这个分享的视频中，以一个线上性能问题的自然暴漏产生的一个具体的需求为例，去分析架构不合理存在的潜在隐患，并以一个具体实用完整的方案（包括架构图、硬件状况、业务分析）为例步步引导大家如何去撰写优秀的系统运维架构的调整解决方案并说服领导者以身推动方案的实施，教会大家在企业中如何做。这个案例非常具有典型性，也对正在成长的运维工程师们是个很好的启发和教育。

初级运维是解决问题，中级运维是提出问题，而高级运维是发现问题并引领问题的解决。要写出一个优秀的系统运维架构解决方案，必然是对当前的系统架构非常熟悉，关注到问题并发现潜在的问题，并通过测试得到可信的数据，下一步通过开会讨论让大家信服并得到领导的认可，继而推动方案的实施，最后确定方案具体的实施人员和部门协作，成功完成方案的落地和实现，可以说每一个细节老男孩都说到了，发自肺腑啊。

开会讨论环节，优秀的运维人员应该有非常好的演讲能力。一个优秀方案的提出，肯定是经过你细致认真思考的，对可能出现的问题都有经过你的测试并且有数据来支撑你的想法和观点，所以表述的时候你应该充满自信，这样大家自然会相信你，选择你的解决方案。同时要注意做两套方案，可供老大参考和决策，让老大做选择题而不是问答题，如果大家认可和接受了你的方案，自然风险大家同担，出了问题也不会都怪罪到你头上。那么演讲能力的培养，大家也不用担心，一回生二回熟，什么都是练出来的，好东西就要讲出来，自己应该最有信心才对。

三、新技术的关注和运用

运维人员另一个创造自己价值、加快自我成长的方法就是要加强对新技术的关注和应用。举一个例子，某公司的小李是一名普通的运维工程师，在公司里工作两年后一直没有什么提升和加薪的好机会。但是他非常喜欢和关注虚拟化技术，经过认真学习研究一段时间后，花半个月写了一份优秀的虚拟化解决方案，针对本公司目前的开发测试的快速部署和迭代需求，从虚拟化的节省成本、快速部署、实时迁移、资源动态分配等角度完整全面的分析了存在的问题并经过自己测试得到的数据验证了自己的构想和解决方案。当他把这份报告提交到领导那里后，经过开会讨论，领导采纳了他的虚拟化解决方案，并提升他为虚拟化架构主管开始负责实施部署和应用。小李成功的从普通运维工程师转变为虚拟化主管，实现了个人价值的提升。当然我们身边这样的例子不少，相信大家都会有感悟，更知道该怎么做。

运维是一场没有硝烟的战争，面对不断变化的系统和架构，学习技术的同时更要学会发现、思考和成长，我想这正是老男孩告诉我们的。
原文地址：http://blog.csdn.net/libin_1/article/details/8277708