作者:罗穆瑞
来源:http://www.cnblogs.com/kazihuo/
总之,阅览后如获珍宝。当然,作为一个运维小哥,以下内容及规则(涉及系统大体)自个儿能驾驭的是少之又少,但丝毫不影响我的向学之心!那是我的工作之心所向,那是我傲娇之心所追,更是对自己能力提升的同时而注重的自我升华。
以下是本人根据书籍内容及些许的自我认同而提炼出的部分精髓(至少自己是这样认为,^_^),个人感觉,有一部分适用于运维人员,而有一部分适用于技术管理人员。相信也存在许多像我一样的IT小哥哥小姐姐,所以希望做个分享,希望能让有需之人观后有感!为啥我要总结出这两种人群的适应内容呢?呃,毕竟,不想当将军的士兵不是好士兵~
对于运维而言,平台、工具、知识、经验,意识等都固然重要,其都在某种程度上决定了运维质量。而对于运维规则,也不可小觑,整好了也许会有四两拨千斤的效果哦!
1、勿重复劳作
不要重复劳动力,也不要什么都从外部获取,如工具、代码、框架等。需要考虑的是在合适的时间以合适的成本切入,投资回报率也是需要考虑的。
一般来说,每个公司都存在重复造轮子的现象,而且许多人都热衷于此,可能需要用这样的项目来证明自己,而却忽略了投入/产出比这个重要的指标。如果能够充分利用社区的成果,利用公司已有的成熟框架,那么可大大加快自己的项目进度,因此,为什么非要自己做一个呢?也许有些人考虑的是重复造轮子,可以真正锻炼到团队,毕竟一个从头开始的项目,所积累的经验往往比一般项目多得多,有助于个人的成长和公司后续项目。
2、允许出错
人非圣贤,孰能无过,运维也是如此!出错并不可怕,关键是要建立机制,让错误能够尽可能快速地被修复,限制错误影响的范围,同时要归纳总结,从错误中让个人成长,让组织成长。
当然,允许出错并不表示事无巨细,均可犯错。允许出错是建立在大体层面上已尽可能的完善了整体制度,规范了运维流程等情况下出现的无可预知的错误!
3、设置备用
4、定位瓶颈
5、重视工具/平台
6、分工明确
![](https://filescdn.proginn.com/0aded94938cc11b4d37244976a5dcd60/952a8649e3e21cced1cce1bcf58b5974.webp)
7、善于分享
8、重视例会
![](https://filescdn.proginn.com/e037b9e9fa016d40e31bc6a8774e6ce3/44a979598fd7b3466c3d06d865df0695.webp)
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方式)
点亮,服务器三年不宕机