运维小哥谈规则

  1. 云栖社区>
  2. 博客>
  3. 正文

运维小哥谈规则

卡子火 2019-01-28 21:41:50 浏览527
展开阅读全文

       作为一个IT小哥,在阅览技术书籍时,看到作者对运维规则的总结,反复阅读几遍后,发现其内容言简而意赅,质朴而真谛。些许认知是我自个儿明白,而无法用言语总结的;些许是让我自个儿从无知到认知的;些许是我想要做而目前作为一个运维小哥而无法做到的~~

       总之,阅览后如获珍宝。当然,作为一个运维小哥,以下内容及规则(涉及系统大体)自个儿能驾驭的是少之又少,但丝毫不影响我的向学之心!那是我的工作之心所向,那是我傲娇之心所追,更是对自己能力提升的同时而注重的自我升华!

       因为,我命不由天,莫欺少年穷!

       以下是本人根据书籍内容及些许的自我认同而提炼出的部分精髓(至少自己是这样认为,^_^),个人感觉,有一部分适用于运维人员,而有一部分适用于技术管理人员。相信也存在许多像我一样的IT小哥哥小姐姐,所以希望做个分享,希望能让有需之人观后有感!为啥我要总结出这两种人群的适应内容呢?呃,毕竟,不想当将军的士兵不是好士兵~

       对于运维而言,平台、工具、知识、经验,意识等都固然重要,其都在某种程度上决定了运维质量。而对于运维规则,也不可小觑,整好了也许会有四两拨千斤的效果哦!

       以下内容是本人摘录技术书籍内容,同时加上了些许个人感知及个人言语,不喜勿喷哦!


# 勿重复劳作

       不要重复劳动力,也不要什么都从外部获取,如工具、代码、框架等。需要考虑的是在合适的时间以合适的成本切入,投资回报率也是需要考虑的。

       一般来说,每个公司都存在重复造轮子的现象,而且许多人都热衷于此,可能需要用这样的项目来证明自己,而却忽略了投入/产出比这个重要的指标。如果能够充分利用社区的成果,利用公司已有的成熟框架,那么可大大加快自己的项目进度,因此,为什么非要自己做一个呢?也许有些人考虑的是重复造轮子,可以真正锻炼到团队,毕竟一个从头开始的项目,所积累的经验往往比一般项目多得多,有助于个人的成长和公司后续项目。

# 允许出错

       人非圣贤,孰能无过,运维也是如此!出错并不可怕,关键是要建立机制,让错误能够尽可能快速地被修复,限制错误影响的范围,同时要归纳总结,从错误中让个人成长,让组织成长。

       当然,允许出错并不表示事无巨细,均可犯错。允许出错是建立在大体层面上已尽可能的完善了整体制度,规范了运维流程等情况下出现的无可预知的错误!

       只要存在硬件载体,就必然伴随着各种各样的故障。有时为了追求高可用性,设计复杂的架构,或者准备过多的冗余设施,往往会导致解决方案的成本剧增,而解决方案的复杂性,也会为后期的改造及维护增加难度。国内众多公司都号称可用性高达99.99%,甚至高精度的小数点后面多加好几个9。然而,某巨头企业的云产品导致小公司数据丢失,某巨头企业应对活动日出现页面异常等等场景,让我们情不自禁的感叹~~

# 设置备用

       备用角色在运维工作中可能只被人看到日常运维的价值,而当主要角色因事请假、过度劳累、因故离职等时期,备用角色价值凸显,他可让正在进行的项目不被打断,正在进行的工作不陷入被动。高效培养备用角色,其需文档、流程和规范的支持,故运维规范等也是重中之重!

# 定位瓶颈

       不监控,无运维。此话说明监控的重要性,对于一些资源的争用,通过监控系统能够直观的反映。而对于一些隐藏较深的资源瓶颈和系统瓶颈,往往需要利用工具,靠经验去分析和判断。作为运维,需要有意识的尽可能地通过监控系统去发现问题,让监控系统变得越来越智能,越来越少地依赖于人的经验。

       高级工程师和初级工程师有一个很大的区别,高工知道如何去定位瓶颈所在。他们不仅知道如何使用工具,还知道何时、何地、为什么要使用这个工具。这样,才可能在问题爆发之前,就定位到瓶颈所在。

       当然,定位瓶颈,单一化的运维知识可能满足不了需求,因为数据可能要经过很多环节,如本地电脑、浏览器、DNS服务、负载均衡设备、应用服务器等。

       所以,应该尽可能的涉猎不同领域的多元化的知识。

# 重视工具/平台

       许多互联网公司都有基础平台的技术部门,专门负责开发基础平台、工具和服务,提供给各个应用研发团队使用。但这往往是一个短期内难以见到效益的事情。对于业务规模不大的公司来说,更多的时候是在做一些技术储备的事情。基础平台部门往往是伴随着公司的高速发展而壮大的,研发出来的产品如果没人用,自然就得不到改进,然后就更加没有人使用,如此恶性循环。其情境往往考验高层的决心,考虑是否需要继续坚持保留适当比例的底层平台开发人员呢?

       应用软件的研发和平台工具的研发毕竟是不一样的,如果基础不牢,可能造成更大的业务风险。所以长远来看,使用部分人力(高素质的工程师)做平台和工具,其实是节省成本的!

       硅谷的一些公司,让优秀的人去做平台和工具,并提供最好的待遇,给予足够的尊重,对于他们的衡量标准也应该不同!

# 分工明确

       大规模的系统架构体系的维护,离不开训练有素的工程师,他们需要有许多知识、经验和技巧,也必然分工明确,如开发运维平台的、专门数据操作的、性能调优的、源码优化的等等。优秀的团队可能还有项目经理、质量管控、文档编者、成本分析、培训教育等各个专业领域的人,不同岗位的人员在自己的专业领域发挥优势,各司其职,才能使整个项目的光彩洋溢地淋淋尽致~

# 善于分享

       应该多参与业内技术交流,对于一些问题,也许有些公司能有更好的解决方案,如果你分享了经验,同行们也会分享经验。从某种角度上看,两者是竞争者的关系,但是如果需要发展,就要看看业内的竞争对手在做什么,要跳出公司的格局去看待技术和管理问题。

       同时,参与业内的技术论坛不仅仅是关注行业技术趋势的一种手段,也是一种招聘方式,通过认识更多人,扩大影响力,吸引更多人加入自己所在公司。自我人脉扩展的同时也充实了公司的发展,何乐而不为呢?

# 重视例会

       许多管理者忽略了周会与例会的重要性。若长期不重视,整个团队就可能变得松散,没有凝聚力。

       周会的一个重要作用是讨论分工。随着机器规模的扩大,人员的增加,团队管理者都需要分工明确,责任到人,才能促使员工尽可能的恪尽职守。

       周会也可讨论彼此的工作进度、交流未完成工作的对策、互相了解团队成员的工作状态、传达上层领导的指示、交流技术与分享等等~~~

       总之,每个人的工作饱和度及个性等差异化,如果没有有效的沟通,关系可能就会像从果核中慢慢腐烂到表皮的水果,彼此互有抱怨。因此,固定一段时间进行正式的交流并成为习惯是值得推荐的沟通方式,同时也可使得同事关系融洽,人员氛围优升~

# 绩效束缚

       关键绩效指标(KPI)是指用于评测组织中与关键目标或关键成功因素,许多公司到了一定规模后,都把KPI考核作为一项主要的管理工具。

       而事实是绩效是一种工具,人却是复杂的,管理人更是一件复杂的事情,要想面面俱到,很难靠绩效这个工具来简化所有的问题。当然,很多东西量化之后,就显得比较好管理。对于产品经理、运营人员、销售人员等等而言,量化指标,往往是看的见的数字。而对于运维及部分职位,可能就很难有一个量化指标!

       绩效的设计应该是帮助个人发展,帮助员工赢的尊重的,而不是用于桎梏个人的。当个人的价值观和企业的价值观起些许冲突时,但凡一个好企业,往往具有包容性;而当冲突严重时,同时个人又不能妥协时,可以考虑换个环境,避免继续在一起的双方损失。

       在书《赢》中,管理大师杰克·韦尔奇运用绩效造就了伟大的文化,而不容忽视的背景是,他花了许多年创立了坦诚沟通的企业文化。如果没有坦诚、没有沟通、绩效可能会成为破坏企业文化的杀手。在推动工作进展的时候,不是去考虑对公司是否真的有帮助,而是主要去考虑自己的绩效,是一个非常不好的倾向。自己现有的工作成果,工作输出,决定了自己后续的工作方向~~~

# 优化设计

       应该有意识地优化流程设计以提高工作效率和服务质量。随着公司业务的发展,运维部门也会随之扩张,如果缺乏合理的流程或缺乏高层次的人才,那么往往会出现一个问题:人数增多了,效率反而下降了!因为随着公司规模的扩大,所管理和维护的资源急剧膨胀,出于安全和其他因素考虑,设计了各种各样的流程,以便得到正确的执行结果,但有时这些流程可能会导致效率下降,部门内部的沟通成本也越来越高,这都需要运维人员对流程本身建立反馈和优化的机制,有意识地不断优化流程!

网友评论

登录后评论
0/500
评论
卡子火
+ 关注