IDC运维抱着这种心态能成功？

运维要带着耻辱感工作，才能让运维的价值凸显出来！

    觉得自己很累，是吧？累就是因为我们每天做一些没有让自己觉得很有成就感的事情，当然很累。

    觉得自己苦逼，是吧？苦逼是你做得很辛苦，然后还没有认可，而你总觉得自己做了很多，你当然心里会觉得苦逼。

    觉得自己很Low，是吧？Low是没有把运维做出格局，更没让别没有看到你的格局，别人会觉得Low，自己也会觉得很Low。

    对于运维执行人来说，以上情绪几乎都是标配的，那到底是什么原因导致的呢？不得不承认运维是一个很难取得成就感的工作岗位。运维人没有耻辱感，便把很多不合理的东西看成一种常态化，失去优化的动力，也就没有了未来美好的运维图景。我们可以把以下不足标记为我们的运维耻辱。

    运维团队缺少体系和全局观的支撑，导致运维后面的阶段性发展是碎攀降摹Ｋ槠式的运维工作推进，运维人或者周边团队自然没法理解运维工作的意义和价值。

    体系是要求运维团队能给出整体的运维框架(价值维度、平台维度、团队定位、运维能力体系等等)，基于这个框架给出阶段性的演进路径图(阶段性重点和非重点方向是什么?阶段性迭代方法?)，然后分解到当前团队或者个人的工作事务中(工作内容)，这样可以把规划层面和底层实施层面真正的打通起来。这个体系不仅仅运维团队内需要，外部团队同样需要，一个很好的沟通媒介。

    无疑，一个运维团队没有整体规划是最致命的，就是无本之木，无水之源。

    一个运维团队的定位和格局决定了整个团队未来的用人策略和后续的发展方p，这几乎是运维团队的普遍问题。很多公司把运维团队定位成一个技术支撑部门，干苦力活的。而运维团队自己也把自己定义成一个服务部门，给研发提供技术支撑的，甚至还用传统的维护观点来定位自己。这些定位有时候甚至是自上而下传递过来的，领导很习惯性的认为，运维是一个成p性、技术支撑团队，他们只是来保障服务稳定的。反推到前面运维招聘要求，便对运维人的能力要求非常的低。带来一个可怕的后果是，运维就进入到一个低价值交付的怪圈中，别人也就认为你只能做这个了。

    运维团队一定要把自己Push到技术运营角色上去，在技术运营的定位上，运维可以提炼出很多模式化的经验产品，带着这个经验产品去覆盖更多的业务----持续交付、自动化发布、配置管理、IT服务管理、端到端监控、技术运营分析(贴合业务的)等等。

    如果现在有人对运维团队的定位还是那种服务支撑的团队，这种运维团队也便没了格局，是一个不合格的运维团队，要时刻记住自己能为用户创造什么价值。更要极度批判的是，把运维定位成是支撑研发的，一些研发团队甚至把脏活累活丢给运维。

    封闭有很多种，我把它称之运维能力封闭，因为这都是运维能力的不足。信息封闭是能力封闭的一种，运维没有想过把自己手头上掌握的技术信息开放给开发，大部分的原因都是说信息敏感，殊不知信息在全员中流动起冢才能产生价值。

    还有一种能力封闭，就是不合作，很要命。运维工作其实是需要和研发、测试深度配合，如运维的标准化和自动化推动。运维可以成为巧妇，而不是莽夫。

    运维必须要有合理的强势，特别是自己应该要做的东西，比如说权限回收、运维标准推进、部署平台、架构服务化等等。这就如同一场象棋比赛，运维不能给自己设定楚河汉界，只要是合理的，为业务可运维性目标而去的，彼此诳梢钥缃纭８自己划定职责范围，就让自己的能力发挥收到制约，个人能力的制约带来的也是团队发展制约。

    合理的强势，是建立在一些核心原则之上，比如说面向用户的服务保证、面向服务的IT性能、面向业务的可运维性、平等合作诘取５很多人会说事实没有这么简单，那是因为人不愿意简单，而我说事实就是这么简单，不是么?我很反感的一个借口是"历史原因"。合理的强势需要建立在平等合作的基础上，这不是你强我弱，此消彼长的游戏，而是共赢成长。

    合理的强势一定程度上可以为运维争取一定的话语权，确保运维在合作的时候，不至于处于被动的状态。注意这是合理的强势，而不是无谓的强势。

    对运维个人说，砭常会和我的团队说每天的运维状态在你身上有什么不同。如果每天都一样，就麻烦了，意味着年末和年初的你是一样的，没有变化。很有意思的一个现象，运维执行岗很容易陷入周而复始的简单运维事务循环，比如说处理故障，分配资源，支持服务上线等等。忙碌的感觉会安慰自己，至硖焯煊泻芏嗍虑楦桑另外会成为自己不思考、不改进的借口。

    我建议，运维人一定要多想想如何让今天的自己和昨天有所不同。首先要把每天重复的事情能否变成自动化的工具，让机器来代替人做，这也是一种价值提升。其次跳出运维砀谖灰求和局限，看看业务是如何运行的?看看身边优秀的人是怎么做的?看看周边团队的技术产品原理是什么?看看公司的测试和研发是怎么做的?看看业界现在发生了什么?这些都能够带来很多的反向思考。很多人说运维了解那么多干什么，其实这些东西学习了某天一定会在你的内心发酵。

    这真的是一种愿景了，我一直想把运维变成软件设计哲学和公司文化的一部分，在早期的程序设计中，应该让"可运维性"变成架构设计的一个重要标准，如同Ｊ砸谎。正如现在很多人在谈运维革命一样，真正的革命一定是在这个层面上，技术带来的变革力很小。如果有一天研发在早期的软件设计的时候已经就开始考虑可运维性，此时真的就不需要运维了。然而事实所展现出来的，我又是如此的悲观，从国内的测试发展历程又可以看到运维的发Ｇ榭隽恕

    我始终觉得，运维人要把这些耻辱感记在心里，如此才能不断的想去如何改变运维的不足。耻辱感在了，运维的能量也便有了，最终便能爆发!运维人有责任和能力给运维职业展现一个更好的未来，不是么?