我的运维故事 推荐

做了这些年的运维，或多或少有些感悟，有成功时的喜悦，有失败时的伤感；多多少少有些学习的经验与工具；分享共勉。
记得第一份工作岗位的名称比较奇怪，叫EDP，可能是电子数据处理吧；开始接触SQL server的数据库，服务器用的是IBM AS400。那时候和大多数刚刚毕业的人一样，跟着前辈进行“传帮带”的学习，也就把一些日常的操作告诉你。记得同事问我，会做水晶头吗？第一次看到压线钳原来长得是这样，测线仪是这样用。至今能记得颜色的位置，还保留着这个测线仪。学校里的那些知识根本不够用，比较庆幸的是那时候可以google；用的是“网文快捕”做笔记，当然是破解的。同事都是年轻人，抽几根烟，喝几次酒就是兄弟了；没有事情就和他们跑机房、搞弱电、弄弄无盘终端，真的涨了很多见识。新人嘛，哪里需要去哪里。那些知识真的太实用了，现在都用的上。
后来搞起了oracle、AIX，也就是从这里开始科班出身就显得比较重要了。范式、叉树等等都来了，这些理论使后面的学习轻松起来了。看到别人用mindmanager觉得不用收集别人的网页了，可以开拓真正的自己笔记了。那时候也到chinaunix发布了几篇博文，可惜没有坚持住，或许那些文件的含金量太少没有被大家认可，自己也失去了兴趣。这段时间我认为是自己提升最快的时候，有环境可以试验，有个大拿在背后解惑，爽啊；可惜的是错过了2010年（可能是那年）oracle有个OCM人才培训计划，没有和同事一起参加，2人都过了，后悔终生呐，不就1W多嘛，有机会去考个实用的技能证书。记得那时的领导是个勇于创新的人，带来我们搞OA、MAIL、安全设备、甚至ERP，签采购合同送了很多原厂培训；现在回想起来，我们部门索取的太多（那些都是真金白银买的），而带来的价值没有显现出来。这个ERP选型用了一年半时间，大到SAP，小到天心，招标招了2次，确定了一个国内知名软件；之后专门买了新设备，建了培训室、办公室，组织了项目组专职/兼职人集中办公；可惜我没有支持到ERP的验收。大概在交付前1个月我闪人了，或许当时太冲动了，心里一直担心着这个项目会失败，数据会混乱不堪，我是怕了，当了逃兵。可是后来，这个项目还是一直在用，据说好不错。想想后悔了，真应该坚持等到erp上线后用一段时间，至少简历可以写写熟悉ERP管理，而非什么选型实施了。
换了工作后，还没有转正就到一个新部门，是个互联网项目；对于一个外援来说真是幸运，如果有想跳槽的朋友，好好考虑，不只是钱的问题。这个只有10人不到的团队，起初让我有个创业团队的感觉，产品规划、代码review、上线部署计划都是在老大的带领下全员参与；也就这时候，我知道作为一个it技术人员能知道或者理解产品业务规划是多么的重要，首先是沟通无障碍，再者开发设计更贴切，最后的维护反馈更准确。
前1年多，整个在吃老本，除了赚点经验值外，技术收获很少，这可能是个学习到实践再学习的过程；记得第一年要过年了，随着业务发展，用户马上要过20W了（5W活跃用户），系统负载已经极限了，那个担心啊，只有3台机架server，这个年怎么过啊，改造、优化各种都来，抗了过来，抗压值直线上升。到我走的时候（对，我又跳了，原因很多，那可是我认真付出的5年），用户总数1.8亿（日活跃2kW），物理机500多，分布在3个IDC，已经健康稳定很多了。
能力的提升在后几年，做管理了，建立了几个人的团队；在爆炸式的业务增长面前，精力全投入到了系统集成上了。建议书，可研报告，实施方案一遍一遍的写，平均一年一期的集成节奏，深深体会到了初稿到终稿的艰辛；不断引入新技术，缓存、分布式、虚拟化、读写分离，oracle迁移到mysql，后面就炒各种概念IASS、PASS、SASS、各种云等等。这段时间我犯了致命的错误，走入了假大空的道路，规划是美好的，往往由于对技术的把握不够、成熟度、风险等因素导致 设计愿景被推到下一期建设目标中，到现在数据库迁移还没有做成；通过这些大大小小的评审会，知道了高层一般思维模式，尤其在与接口人的接触中，学习到了很多，逐步建立了自己做事的原则，是的，原则、红线。其中有两期比较大的项目，200多台设备，从上架到交付，只用20多天；天天是计划、沟通、协调、核验的事情，时间紧任务重；有点遗憾是，没有与网络厂商一起搞，每次都想下一期跟着，导致现在只能做一些普通网络交流与设计，机会不等人，不知道下次有没有机会了；另外一个技术就缺少一门真正的语言用于运维开发，perl做整合差了一点，所有需要在学习Python，来实现自己的想法。
接下来就是如何管理这些机器的事情了，有困难找领导，走，找领导去，此时发现我们已经很久没有沟通过了（他是空中飞人，我不是在机房就是在机房的途中），时间都去哪里了？平时没有时间去沟通吗？记住，有事无事向领导汇报哦。几次交谈，得到了领导对工作的肯定，平台鲜有故障了，公司的人都忘记运维的存在了，现在还在靠人管理吗？是啊，维护的价值仅仅在于建设系统，保障系统吗？从那时起，明白了，需要显现运维的价值。建设各种系统，监控、部署、知识、论坛等等。但是完成后我没有丝毫的成就感，而是无力感。应用越来愈多，系统越来越复杂，技术越来越先进，可是还是感觉很累，心累的那种感觉。不知道问题出在哪里？
再后来，没有后来了，随着第一个队友离开（上下争取了很久），我知道这个5年没有离职记录的团队散了，还会有第二个第三个；这里我也有责任，队友们被我惯坏了，团队建设在初期可人治，但后期需进行法治。6个月后某某项目结束，我也离开了；走的问心无愧，对得起任何人。原因太多，多说无益。这个战斗过的地方，留下了回忆，也留下了我的遗憾和疑问。
伤感的话题不说了，我的问题还没有解决了。心静下来，这次机会再次眷顾了我，要人有人，要环境有环境，要规模有规模，可谓天时地利与人和，可以完成自己的夙愿。这些年下来，技术在退化，不google可能出来不了具体问题了，所以自己定位类似项目经理、架构师的角色，促使团队与运维中心的共同建成。

写累了，后面具体规划就不赘述了，敬请期待我的博客吧。

先框架，再细节；
提供服务；
能力输出；
以业务角度分析系统状态；
资源整合；
流程控制；
知识技术共享（显性）；
团队建设；
分析；
工具不是关键，是如何用好工具；
先阐述问题，再解决问题（《你的灯亮了么》）