运维小哥谈规则

布满荆棘的人生 2022-02-14 12:24 165阅读 0赞

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

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

因为，我命不由天，莫欺少年穷！

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

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

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

\# 勿重复劳作

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

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

\# 允许出错

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

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

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

\# 设置备用

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

\# 定位瓶颈

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

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

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

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

\# 重视工具/平台

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

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

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

\# 分工明确

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

\# 善于分享

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

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

\# 重视例会

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

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

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

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

\# 绩效束缚

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

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

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

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

\# 优化设计

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