当我在谈论运维的时候,我究竟在说什么

我是个9年经验的运维老兵。

和大家聊聊,当我在谈论运维的时候,我在说什么?

当我在谈论运维的时候,我究竟在说什么

关于定位

运维和开发,是任何一家IT公司中都非常常见的两大岗位。

也是devops中绕不开的两大事务,一个创造产品一个维护产品

运维之于开发,好比球场中的后卫之于前锋、相声中的逗哏之于捧哏、机场的地勤之于机长、战场上的炊事班战士之于前线战士

是选择当前锋还是后卫?是做机长还是当地勤?是去炊事班还是上阵杀敌?

一个在前、一个在后;一个创造价值,一个保障价值

我想大部分的人都会选择第一个选项,毕竟创造价值所带来的荣誉感最直观。

很多人觉得运维的工作不像开发岗位容易出彩,即便是正儿八经出彩的时候,十有八九也是伴随着事故的发生。

一个运维的日常:
一切正常:我们花钱请你来干啥
系统异常:我们花钱请你来干啥

相反,运维工作中比出彩概率更大的,是我们常常开玩笑说的;许多运维同学对职业前景无望,只是卑微地祈求自己任职内无锅无坑地过下去。

有人说,没有哪个运维大侠职业生涯期间没背过锅,这些出其不意的黑锅让你成为了更好的自己,所以,请好好感谢这些锅。

要是按这个理来说,我也觉得背锅是件好事,它好就好在,它好NMLGB。

我相信没有正常人愿意背锅,产品的生命周期经历了市场调研设计开发测试,最后上线运营,由运维扶着,怎么出事了就成运维的事了呢?运维是离事故最近的一环,但一定不是必然的一环,更何况中间有可能还隔着各类规程制度流程审计等职能环节。

所以,当事故从天而降在所难免的时候,你知道问题不在你这,就请广大的运维朋友们保持自信而不失礼貌的微笑,你的自信能给惶恐的其他同事带来很大程度的安全感。

那么

当我们在谈论运维的时候,我们是在讨论如何无锅无坑地过这一生?


关于职责

当我们面对一个运维工程师的时候,我们很可能面对的是一个复合型选手。

他所从事的专业在很大可能上跨越了不同的操作系统、跨越了不同的编程语言、跨越了技术与业务,所交涉的团队很可能跨越了开发、测试、产品,乃至财务

如果说开发能力最后所追求的境界是深度,那运维讲求的是广度以及深度

下面是我从网上随便搜的一则来自某大厂的运维工程师的招聘要求:

1、深入理解运维体系结构,精于容量规划、架构设计、性能优化;

2、熟悉服务管理、单元部署、自动扩容等运维系统建设,对成本控制和效能提升有深刻的理解和实践

3、熟悉故障、监控、限流、降级、预案、扩容工作原理;

4、深入理解Linux、apache,tomcat,jboss,nginx系统原理,具备问题分析和快速处理能力;

5、熟悉SHELL,PYTHON,PERL等脚本类编程工具,并有使用提升效率案例;

6、熟悉java虚拟机,对java应用的部署及系统优化有一定的经验;

7、熟悉Java,Php,C++等编程语言优先;

8、熟悉自动化发布工具、熟悉虚docker技术优先;

仔细看看这份JD,我们试着分析这个岗位的技能属性要求:

首先,大家有没有注意到,JD前3项都没有提及具体的技术或语言要求,提到的都是思维能力,可以理解为技术经验的积累和软实力;第4项之后才是具体的与业务相关技术栈熟练情况。

其次,我们可以看到JD有提到"具备问题分析和快速处理能力""有使用提升效率案例"等字眼,也从一定程度上表明了运维工作的核心关键——分析问题提升效率

一个岗位要求熟悉多种开源工具、了解业务线、会用各类工具、懂点开发,想必只会是运维岗了。

所以

当我们在谈论运维的时候,我们是在谈论的如何学习各种系统和工具?


如何起步

是不是总有人(就是我)会习惯性地吹牛批说,“我拿公司的产品当自家儿子一样照顾”?

所以,如何开始你的运维生涯,以我的经验来看,首当其冲的是要接纳自己的产品,把它当成自己的孩子。

首先,你得爱它,这是基础,也是非常必要的,是你开始一切运维事务的前提,不热爱你的产品,不一定会出事,但一定是做不出彩。虽然这产品会虐你千百遍,但你知道,你每一次把它扶正,都是在帮它成长为更好的它。

其次,你要懂它。懂它的脾气,它的弱点,它的给人们带来了哪些快乐,为人们带来了哪些生活上的便捷

最后,你要守护它。守护它的安全,保障它的性能,要非常敏感地感知它的不适,做好预警和通知,并且快速地提供解决,哪怕是在凌晨或夜里。

当你站在父母的角度来看产品,你的一切工作似乎都变得有那么些意义了。

所以,试着说服自己或催眠自己,“像照顾自己的孩子一样照顾好公司的产品”。这不是一件容易的事,某些程度上,运维工作的内容本身就是一个类似父母的角色扮演行为,吃力不讨好,是这份工作的常见情况

所以

当我们在讨论运维的时候,我们是在互相吐槽然后抱在一起哭?


关于发展

从职业发展的角度,运维工程师个人的技术栈严重依赖于你所维护的产品(当然开发岗、测试岗也一样)

所以,充分地熟悉你所服务的产品,可以帮助你快速地扩展工作当中的思路。

这便是你从爱它、懂它、守护它的过程中,给自己带来的收益。

所以,当你来到了新东家,建议你首先需要确定几个事:

  • 1、我要维护的是个什么神兽?(认识一下你认领的熊孩子
  • 2、我要面对的是些什么样的神仙用户?(认识一下你的爸爸们
  • 3、开发过程都用了哪样的技术栈?(将来出事了也知道从哪下手
  • 4、我的职责范围都包括了哪些?(确定雷池边界
  • 5、如果有条件,和前辈了解一下以前都出现过哪些大级别的故障?(万一再次出现却没有充分准备,你可能会死,别问我为什么会知道)
  • 6、办公室的最优逃生路线?(便于随时跑路)

当你对所提到的除第6点以外的所有事项都有了深刻的认识之后,如何通过自动化、规范化、流程化的操作方法提高运维效率将是你下一阶段需要严肃考虑的问题

俗话说,“天下武功唯快不破”。社会本就是个江湖,这话在江湖中的任何一个领域都适用。

如果说运维工作千万条,稳定第一条,那么效率一定是“维护稳定”的基础能力。毕竟我们在很大程度上如同消防员一般地存在,一次优秀的事故处理过程,往往是做到了提前预警快速响应快速定位快速解决。而这无不依赖于规范的流程体系、完备的监控告警系统、高效的自动化系统才能得以实现。

运维体系建设从0到1、从无到有、从有到优,当你带着顶层思维至上而下地建设了规章制度管理流程系统工具,相信你的个人技能也将会得到极大程度的发展。

所以朋友们,当你处于迷茫时期不知道提高什么技能的时候,请跳出技术本身看运维,围绕着正在进行的业务展开思考,你将收获的可能不仅仅是技术。


结论

说到这,我在谈论运维的时候,我谈到的到底是什么?

高度的责任心职业道德

7*24无时不刻的关注和待命

是持续不断的学习和自我提升

是强大的内心和抗压能力

是在职责范围内,本着对产品和用户负责的宗旨,使用技术和工具保障产品的稳定,提升产品迭代速度,并从中抽离出的流程、规则和方法。

-----------------The End -----------------

原文地址:https://www.cnblogs.com/wymanwang/p/12511615.html

时间: 2024-10-08 18:39:45

当我在谈论运维的时候,我究竟在说什么的相关文章

公开课|一个小运维的《Golang 入门心路历程》

成功不是将来才有的,而是从决定去做的那一刻起,持续累积而成. 视频版 公开课主要内容: 缘起 初识 熟悉 实践 爱上 缘起 本人之前是 hadoop hbase 运维,为了节约成本 hadoop client 都是多用户的,也就是不同的业务线在同一台机器上.导致一个问题就是一个业务资源占用高,跑死其他业务线.在这种情况下我就想如何解决这个问题呢?这时候我接触到了 Docker--实现资源隔离.随着对Docker的深入了解以及身边人经常谈论 Go 语言,我感觉 Go 语言很牛,平时开始慢慢关注 G

从十年运维看“云”维趋势

又到岁末,就这样默默地在运维行业里已有十年余.总是想找个机会总过去展望未来,并给刚上路或是在路上的运维朋友交流一些观点.虽然现在比前几年轻松,但是惰性也随之有增,所以从未实际提笔.但是因为脑子里一直记着这事儿,所以其实一直在脑子中整理文字和框架,结合工作实际,很多观点也经受了验证,并非侃侃而谈.终于因为圣诞假期开始,趁着回国途中有集中的时间写出来,其实也是为了在万米高空消磨消磨时间. 笔者目前在北美某著名游戏公司从事运维工作,十年间发表过不少文章,著有<Linux系统命令及Shell脚本实践指南

[转载]系统运维秘诀大分享专题

系统运维秘诀大分享专题 本专题整合收录了有关系统运维/系统管理员工作和个人成长方面的各种心得分享.经验总结.以及必须牢记的一些准则,适合所有在运维领域有追求的技术人阅读.有些分享的层次比较深,有些则是运维的基础课,但通过翻看他人的心得,相信你总能有所收获. 1 Dormando的系统运维秘诀三部曲... 4 1.1 技术篇... 4 1.1.1 为变化而设计.... 4 1.1.2 使用自动的,可重复的构建过程.... 4 1.1.3 使用冗余.... 4 1.1.4 使用备份.... 5 1.

DevOps 发展融合运维可视化

DevOps,是开发(Development)和运维(Operations)的组合,代表一种文化.运动或实践,旨在促进软件交付和基础设施变更软件开发人员(Dev)和 IT 运维技术人员(Ops)之间的合作和沟通.它的目的是构建一种文化和环境使构建,测试,发布软件更加快捷,频繁和可靠. 现在2016年 DevOps 逐渐成为主流,来自云端.移动和社会等基本需求的驱动将促使越来越多的公司认识到采用 DevOps 最佳实践可能获得的文化.性能和经济效益. 精简灵活的公司已经在过去几年感受到了 DevO

转载:一个老运维的心里话

https://tieba.baidu.com/p/4356267156?red_tag=3195727331 功能介绍 互联网技术分享平台,分享的力量.帮主一直坚信技术可以改变世界,从毕业到现在干了15年运维,有许多话要和你说.熟悉运维自动化,擅长架构设计,熟悉各种云平台技术和产品.负责设计开发运维平台管理体系. 正文其实我本没有想过要写这篇文字,但有次和业内的一位技术朋友聊起当前互联网技术的话题,聊了很多东西,从互联网产业的崛起.蓬勃发展.未来的走向又聊到互联网技术起步.变化.开源.融合..

运维工程师都在做什么?(转)

首先先看图: 下面是运维工程师至少要能做以下的工作: 1,网络工程师的工作 你至少要能配置CISCO 6509以下的设备,熟悉各种网络协议,否则网络出问题的时候你会傻掉. 2,系统工程师的工作 你至少要理解各种系统服务,在出问题的情况下要迅速解决问题,而不是等系统工程师来解决. 3,安全工程师的工作 我不要求你一定要会各种网络编程,但是在服务器收攻击的情况下,没有防火墙的情况下,做一些简单的处理工作. 4,存储工程师的工作 至少要熟悉各个厂商的设备,各种备份和还原的办法 5,测试工程师的工作 在

网站运维技术与实践之数据分析与报警

对于日益积累的监控数据,显然需要有规划地进行存储和分析,做到"故障没来时有预防,故障来临时有提示,故障到来时有解决方案". 一.时间序列存储 对于大多数监控数据,都有一个天然的类似数据库主键的属性,那就是时间.所以,通常情况下,各类监控系统的后台数据库都可以认为是时间序列的数据存储,并由此诞生了一批针对监控数据存储开发的数据库,其中最有代表性是RRDtool和Graphite. 1.RRDtool(Round-Robin DataBase Tool) Round-Robin(循环)在运

如何通过AI 全面提升运维效率?AIOps实战案例在选型宝分享

前言 运维,是企业IT最基础的工作,也是痛点.槽点最多的工作.海量的数据.频繁的报警.艰难的排障.无情的投诉,足以让运维工程师们感到崩溃和绝望-- Gartner在ITOA (IT Operations Analytics IT运营分析)的基础上,提出了AIOps的概念.当时,AIOps的含义是"基于算法的IT运维(Algorithmic IT Operations)".随着AI热潮的到来,Gartner也顺时应势,在2017年的一份报告中,将AIOps重新定义为"Artif

[转帖]老鸟运维的下场

老鸟运维的下场 https://blog.51cto.com/liuzhengwei521/2175886 作者写的挺好 自己需要向他学习. weilovepan520关注0人评论1691人阅读2018-09-17 08:58:20 在国内,技术界里有个自相矛盾的有趣现象——科技人才的短缺和过剩并存.你问任何一个在IT届工作的人,他都会告诉你,招聘一个有能力的人才是如此之难.然而当你再听听那些找不到工作的技术人员们令人心碎的悲惨故事后,你会明白有成千上万的人找不到工作.这又是为什么? 残酷的现实