• 博客访问: 14000657
  • 博文数量: 1495
  • 用 户 组: 普通用户
  • 注册时间: 2012-05-14 23:24
  • 认证徽章:
个人简介

每日发文,或技术、或总结,偶有日间小事也以为记,谓之学习笔记,成年累月1500多天,中间几乎没有间断,要旨只有一个:学习交流,共同进步 。 学习笔记精华整理,个人新书《Oracle DBA工作笔记》已开售,在京东,当当,亚马逊,淘宝,天猫均有售,欢迎选购。

文章分类

全部博文(1495)

文章存档

2018年(136)

2017年(320)

2016年(356)

2015年(346)

2014年(270)

2013年(46)

2012年(21)

分类: 数据库开发技术

2018-04-22 09:20:24

在运维工作中,我也经历和变换了一些角色,对我来说,行业里大家都彼此熟悉,我也会偶尔成为“意见领袖”。但是我发现工作中的事情需要落到实处,基本有几点需要明确:1.有想法 2.沟通 3.做事情的效率和产出 4.团队协作能力

当然这个从空降或者一蹴而就来入手是显然阻力比较大的,除非给你的角色具有压倒性的力量。

所以对于工作的事情我也做了一些思考和总结,总是在想,我的目标是什么,我现在的状态是什么,我现在和目标的差距有多大,问题到底出在哪里?所以我做了一些提炼,有几点经验和建议:

1.无论你是否是专家,都要接触业务

运维的意义是业务驱动,一旦脱离了业务,你会发现做很多事情会比较被动,比如你要做业务优化,但是不知道该怎么去对接业务方;你要做出一些建设性意见,脱离了业务方的反馈,会发现计划和反馈会有很大的出入;越脱离业务,越会纠结于很多不是问题的问题;还有一点是,我觉得更加重要就是,拖里了业务,其实也是增加了代沟,你的成果他无法感知,他的痛点你也无法体会。所以无论你是否是专家,都要接触业务,深入业务,优化业务,纵然接触业务会花掉你不少的时间,我觉得能够阶段性的投入,有针对性的投入,还是值得的。

2.你的工作量

其实我以前还算比较排斥工作周报,汇报工作也是阶段性来做,但是显然从我的角度来说,我觉得很多工作虽然做了,但是工作量很难体现,比如公司会给我安排一个里程碑的任务,同时对于运维工作,我觉得部署安装是基础功能,备份恢复要提前搞定,从技术发展来看,要跟进新技术预研;从业务的支持来说,业务方的需求还要尽力满足,势必会有一个比例的投入和优先级,所以如果只是按照一个核心里程碑事件,其实我可以工作的相对很轻松,但是事情自己不深入来做,已有的问题还在那里,后期要更正会更加纠结,不如提前发挥自己的余热,把这些事情先能搞定,所以我决定做一些改变,就是多承担一些任务,多做一些事情。虽然工作确实忙了不少,但是你会发现,你解决了很多潜在问题,对自己推进工作和给同事减压都是很好的辅助。

3.工作的形式和输出

我以前的认知中对于形式其实不是很看重,觉得事情做好就行。换个角度来理解,可以这么理解,就跟大家去考取一个证书一样,哪怕这个证书现在已经不重要了,市场上的认可价值没那么高,但是你通过自学完成了系统的知识结构,同时也能够结合工作做一些补充,那么这就是一个实质性的工作,那么是否考取证书就是一个锦上添花的状态,我们对于工作的形式和输出就是这个锦上添花的补充。有了当然更好,如果没有其实也可以,但是如果有这么一套考核的标准,是你的干嘛不去争取。如果用数据库来打比方,就跟系统权限和角色一样,系统权限是一些很零散的权限形式,基于对象级,太多了也没人去关心,自己都不记得了,但是如果打包成角色,其实就有一种一目了然的感觉。

4.你需要主动发起一些事情

磨合了很多的事情,如果这个事情的结果导向不是很明确,或者大家觉得这个事情可做可不做的时候,能不能继续做下去,就需要一些核心的推动力了,比如由你来针对性的发起和跟进,否则,一件事情很可能就是不了了之,你觉得大家应该重视,大家觉得应该由你来发起,结果出现了GAP,难免会上火和焦虑,所以我们的生活和工作中有太多的不了了之的事情。就好比我现在发起的自动化运维分享群,比如要推动的一些方向性的事情。

5.无脚本不欢,以手工操作为耻

我在和不同行业和角色的人聊天中,大家对于运维的很多理解都是基础运维,其实就跟最近团建去兴隆上上的玻璃栈道一样,运维就好比是两边的护栏,没问题的时候看起来意义不大,但是自己走的时候发现确实很需要。说明确一些,就是工作中,尽可能脚本化,工具化,流程化来处理问题,尽可能不要手工敲命令来实现,要以手工操作为耻。

运维工作中几点深刻的经验和教训

我觉得我们自身对运维的理解要上一个台阶,如果你的工作内容都是基础运维(服务器部署安装,环境配置,权限开通),那么你的角色就很危险了。这种工作今天可以手工,明天可能就不需要了。

6.小环境里的大智慧

有很多同学都会说自己的公司的环境规模太小,很多不够规范,但是这些问题只有抱怨是解决不了的,或者你一任性一走了之,那么问题在其他的公司都会有或多或少的体现,我要强调一点,任何级别的公司都会有大大小小的问题,绝对有很多是觉得明显不合理的细节。我建议大家不要总是抱怨,抱怨的时候要有建设性的意见,有些公司文化层面,价值观是没法改变的,但是运维细节的改进还是很有实践意义的。

比如我举一个具体的例子,MySQL中的online DDL,如果你要维护管理很多版本的环境,一个500万级别的表需要添加一个字段,那么这个操作该怎么做,如果你手工添加,基本也是秒级就可以完成,但是你如果再用心一些,针对不同版本,使用工具来完成,虽然看起来有些啰嗦,但是就是这些细节能够给你诸多的经验。一旦数据量到了千万级别,你也有了一些基础的经验,你会觉得运维这个活儿是个手艺活。

7.运维的几个进阶角色

运维的路该怎么走,方向有很多,边界也有很多,从我的理解来说,我觉得可以有很多的进阶方向。没有什么事情是那么简单就能完成的,这些方向可以根据自己的能力和定位来针对性的投入。知识更新现在很快,我们的理念其实也要跟进,不断更新。

  1. 开发架构

  2. 运维应用平台开发

  3. 应用内核开发

阅读(4960) | 评论(0) | 转发(1) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册