一名运维小哥对运维规则的10个总结,收藏起来

DevOps技术栈

共 3787字,需浏览 8分钟

 ·

2021-10-22 10:48

作者:罗穆瑞

来源:http://www.cnblogs.com/kazihuo/

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

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

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

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

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

1、勿重复劳作

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

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

2、允许出错

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

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

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

3、设置备用

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

4、定位瓶颈

不监控,无运维。此话说明监控的重要性,对于一些资源的争用,通过监控系统能够直观的反映。而对于一些隐藏较深的资源瓶颈和系统瓶颈,往往需要利用工具,靠经验去分析和判断。作为运维,需要有意识的尽可能地通过监控系统去发现问题,让监控系统变得越来越智能,越来越少地依赖于人的经验。
高级工程师和初级工程师有一个很大的区别,高工知道如何去定位瓶颈所在。他们不仅知道如何使用工具,还知道何时、何地、为什么要使用这个工具。这样,才可能在问题爆发之前,就定位到瓶颈所在。
当然,定位瓶颈,单一化的运维知识可能满足不了需求,因为数据可能要经过很多环节,如本地电脑、浏览器、DNS服务、负载均衡设备、应用服务器等。
所以,应该尽可能的涉猎不同领域的多元化的知识。

5、重视工具/平台

许多互联网公司都有基础平台的技术部门,专门负责开发基础平台、工具和服务,提供给各个应用研发团队使用。但这往往是一个短期内难以见到效益的事情。对于业务规模不大的公司来说,更多的时候是在做一些技术储备的事情。基础平台部门往往是伴随着公司的高速发展而壮大的,研发出来的产品如果没人用,自然就得不到改进,然后就更加没有人使用,如此恶性循环。其情境往往考验高层的决心,考虑是否需要继续坚持保留适当比例的底层平台开发人员呢?
应用软件的研发和平台工具的研发毕竟是不一样的,如果基础不牢,可能造成更大的业务风险。所以长远来看,使用部分人力(高素质的工程师)做平台和工具,其实是节省成本的!
硅谷的一些公司,让优秀的人去做平台和工具,并提供最好的待遇,给予足够的尊重,对于他们的衡量标准也应该不同!

6、分工明确

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

7、善于分享

应该多参与业内技术交流,对于一些问题,也许有些公司能有更好的解决方案,如果你分享了经验,同行们也会分享经验。从某种角度上看,两者是竞争者的关系,但是如果需要发展,就要看看业内的竞争对手在做什么,要跳出公司的格局去看待技术和管理问题。
同时,参与业内的技术论坛不仅仅是关注行业技术趋势的一种手段,也是一种招聘方式,通过认识更多人,扩大影响力,吸引更多人加入自己所在公司。自我人脉扩展的同时也充实了公司的发展,何乐而不为呢?

8、重视例会

许多管理者忽略了周会与例会的重要性。若长期不重视,整个团队就可能变得松散,没有凝聚力。
周会的一个重要作用是讨论分工。随着机器规模的扩大,人员的增加,团队管理者都需要分工明确,责任到人,才能促使员工尽可能的恪尽职守。
周会也可讨论彼此的工作进度、交流未完成工作的对策、互相了解团队成员的工作状态、传达上层领导的指示、交流技术与分享等等~~~
总之,每个人的工作饱和度及个性等差异化,如果没有有效的沟通,关系可能就会像从果核中慢慢腐烂到表皮的水果,彼此互有抱怨。因此,固定一段时间进行正式的交流并成为习惯是值得推荐的沟通方式,同时也可使得同事关系融洽,人员氛围优升~

9、绩效束缚

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

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

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

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

10、优化设计

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

- END -

 推荐阅读 

31天拿下 K8s 含金量最高的CKA+CKS双证书! 
Kubernetes上生产环境后,99%都会遇到这2个故障
如何用 Kubernetes 实现 CI/CD 发布流程?| 漫画
K8s kubectl 常用命令总结(建议收藏)
终于明白了 DevOps 与 SRE 的区别!
我在创业公司的 “云原生” 之旅
基于Nginx实现灰度发布与AB测试
编写 Dockerfile 最佳实践
Kubernetes 网络方案之炫酷的 Cilium
运维工程师不得不看的经验教训和注意事项
Kubernetes 的这些核心资源原理,你一定要了解
搭建一套完整的企业级 K8s 集群(kubeadm方式)



点亮,服务器三年不宕机

浏览 39
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报