运维是数据中心里最为重要的工作，但却常常被人所忽略，这主要原因在于运维的工作是花钱部门，并且投入资金短时也看不到效果。而在运行出了故障时，又要运维被黑锅，将矛头指向了运维。实际上，一个数据中心运行的是否稳固是从其最开始建设就一定程度上决定了，就像一个人一样出身是非常重要的，虽然并不能代表全部。一个数据中心在最开始建设的时候要求就很高，各方面建设非常标准，冗余和备份系统非常完善，这样的数据中心后期运维也会很轻松，故障发生概率很低，即便出了故障也有备份系统正常接管业务，确保业务不受任何影响。不过，就算是最先进的数据中心，也离不开运维的工作，那些声称自己的数据中心是无人值守的，虽然不需要有人24小时在机房监控，可也离不开人管理，还是需要运维的人员周期性地对数据中心进行巡检，及时发现隐患。可以说：“运维工作是数据中心的神经和大脑，IT设备等基础架构是其骨架，而各种接口就是传感器，运维工作可以控制和分析整个数据中心的运转情况，保障数据中心良好运转”，运维的工作重要性不言而喻。
既然运维的工作对于数据中心这么重要，为何长久以来，并不能得到重视呢?首先是传统的“重建设，轻管理”的IT思维禁锢着数据中心运维的工作价值发挥和潜力发掘。在复杂多变的市场环境，快速发展业务为先，只有建设格调比较高的数据中心才能吸引到客户使用，所以数据中心将心思几乎全部用在建设上面，以便吸引到更多客户使用;其次是运维的工作难以量化，不像数据中心建设取得的成果立竿见影。当一个数据中心建设完成后，容纳多少服务器，能开启多少业务，都是可以预知的，很容易获得高层领导的认可。也正因此如此，数据中心架构师的收入要比运维工程师高出很多。的确，架构师只有在数据中心建设设计时投入精力比较多，可一旦建成就和架构师的关系不大了。一个数据中心建设之后，往往有漫长的生命周期，使用二三十年是常有的事儿，从时间长度上来说运维的工作伴随着数据中心的整个生命周期中，可让人印象深刻的一定是其发生的历次故障事件，这本身实质是对运维的工作否定;第三是运维是要花钱的，数据中心随着运行时间的延长，内部各个零件都是失效的可能，数据中心经常要进行零件的采购，这些都需要钱，还有运维的人员工资，各项技术培训和管理支出。总之，各种各样的运维费用让数据中心有时也喘不过气来，运维费用过高往往拖了数据中心建设和扩容的后腿，这些账都要算在运维头上，抱怨运维花钱太多，又不能直接产生效益，数据中心对待运维的态度多是能省则省。这样一来，在数据中心里运维工作开展的并不顺利，很多数据中心运维也是得过且过，只要不出问题一切都好，能不能出问题要看老天了。
冰冻三尺非一日之寒，要想一下子改变当前数据中心运维现状很难。不过，随着客户对数据中心依赖程度的增加，数据中心的运维工作质量将直接影响到客户的业务、市场甚至是形象等，数据中心宕机故障有可能导致数千万元的损失，甚至被监管机构处罚的例子屡见不鲜。在这样的严峻背景下，运维的工作逐渐浮出水面，确保数据中心不出故障仅仅是运维工作的一部分，远远不是全部。运维的工作重点应是如何定义数据中心工作与服务关系，如何建立与客户之间的服务水平协议，如何快速地支持客户业务的需求，如果规划好数据中心建设，更好地为业务部门提供发展动力等。要进行高效运维，而不是将精力全部放到设备运维上去。一定有人会问“不做设备运维，那出了问题怎么办，谁也无法保证设备不出问题”，是的，任何设备都有出故障的可能性，这就需要建设数据中心时做好系统备份，从服务器、网络、存储等都需要备份，甚至数据中心之间也可以备份，这样数据中心出了什么故障都不怕，业务自动切换到其它备用系统上去，以此来确保数据中心业务不受影响，至于设备故障原因交由设备厂家来查，分析出原因后确保下次相同问题不再出就可以。当然数据中心设计的再好，也可能存在漏洞，尤其是在不断扩容和运维过程中经常会出现这样那样的问题，这就需要不断优化数据中心系统，确保发展业务的同时，系统稳定性不受到任何影响。随着云计算和大数据的发展与普及加速了运维趋向成熟，基本上已经颠覆了小企业的运维模式，一场新的运维变革运行悄然兴起。向运维的工作要利润，向运维的工作要效率，是对运维提出的更高要求。新技术的到来势必砸掉大多数不思进取的运维人员的饭碗，普通运维的人员一定要具有创新思维，建设自动化运维系统，提升运维工作效率，否则丢掉饭碗只是时间问题。运维技术人员要有一种职业危机感，不断提升自己的技能水平，要有全局的视野，而不是局限于某些设备，某一类技术。运维的人员还需要不断学习，接受新技术，学会使用一些好用的运维工具，或者自己具备开发运维工具的能力，通过使用这些工具来提升运维的工作水平。以前，运维的人员都是作为数据中心运转幕后工作者，很难为外界所知，甚至数据中心内部管理者也未曾真正关注过。现在，数据中心发展对运维提出了更高要求，需要运维人员走到台前，这给了运维改变历史命运的机会，这样改变运维在未来数据中心中的地位。
作者：佚名
来源：51CTO