运维大局观
2015-08-13 20:28
253 查看
1 拒绝重复劳动,能用程序干活的,坚决程序化、平台化;
比如一些机械性重复性的工作,真正的运维工程师绝不能允许自己重复做三遍以上。
如果不能一步到位自动化的话,可以先尝试半自动解决,然后到全自动甚至到智能化的完美方案。
2 拒绝重复犯错;
人难免会犯错,这是无法避免的
但是能根据已有的犯错经验,总结犯错的原因以及如何避免同类情况再次发生
把一些典型的错误在团队中分享,把一个人的犯错得到的经验传播于整个团队
3 凡事有备份、可回退,有plan B;
运维工作中经常有一些发布、迁移、备份等复杂操作,事前最好做全面的操作计划,思考每一步可能的回退与备份
对每条执行的命令必须double check
4 用技术来解决流程问题;
尽量减少需要人为注意的事件,比如发布文件的打包格式,不能依赖人来维护,必须用程序或脚本等技术来解决
5 通过每一次故障进行学习和提升,再回到第2条;
把错误当作经验值的增加,以及一次团队分享的机会
6 运维部门做到服务化,不要把自己当作边缘部门或纯技术论;
别整天喊苦逼、没地位,埋怨没有意义,应该扩大运维部门的影响力
运维能力的提升不是钻研系统内核、源码就能提升,这是纯技术论,给不了整个公司创造价值的技术是无用的
7 对身边同事要有激励和正反馈;
凡事有正能量,不解释了
8 深入了解所运维的产品,拒绝黑盒运维;
热爱自己的产品,才能更好的了解它
深入体验自己运维的产品,知道有哪些细致的体验或者数据可以反映产品的运营质量,这是技术运营需要懂的
比如一些机械性重复性的工作,真正的运维工程师绝不能允许自己重复做三遍以上。
如果不能一步到位自动化的话,可以先尝试半自动解决,然后到全自动甚至到智能化的完美方案。
2 拒绝重复犯错;
人难免会犯错,这是无法避免的
但是能根据已有的犯错经验,总结犯错的原因以及如何避免同类情况再次发生
把一些典型的错误在团队中分享,把一个人的犯错得到的经验传播于整个团队
3 凡事有备份、可回退,有plan B;
运维工作中经常有一些发布、迁移、备份等复杂操作,事前最好做全面的操作计划,思考每一步可能的回退与备份
对每条执行的命令必须double check
4 用技术来解决流程问题;
尽量减少需要人为注意的事件,比如发布文件的打包格式,不能依赖人来维护,必须用程序或脚本等技术来解决
5 通过每一次故障进行学习和提升,再回到第2条;
把错误当作经验值的增加,以及一次团队分享的机会
6 运维部门做到服务化,不要把自己当作边缘部门或纯技术论;
别整天喊苦逼、没地位,埋怨没有意义,应该扩大运维部门的影响力
运维能力的提升不是钻研系统内核、源码就能提升,这是纯技术论,给不了整个公司创造价值的技术是无用的
7 对身边同事要有激励和正反馈;
凡事有正能量,不解释了
8 深入了解所运维的产品,拒绝黑盒运维;
热爱自己的产品,才能更好的了解它
深入体验自己运维的产品,知道有哪些细致的体验或者数据可以反映产品的运营质量,这是技术运营需要懂的
相关文章推荐
- openstack-juno安装记录
- 定制Dockerfile实现redis cluster的docker化部署及集群管理
- [转]tornado ioloop start 的过程
- docker强制批量删除none的image镜像
- linux系统下载:Ubuntu 14.10 ISO 正式版镜像文件
- 使用iptables管理docker容器做端口映射网络
- Ubuntu安装OpenSSL
- 《学习opencv》笔记——矩阵和图像处理——cvAnd、cvAndS、cvAvg and cvAvgSdv
- 解决docker不能绑定静态的外网固定ip的问题
- 云中双边滤波器——基于opencv图像结构
- Xamarin.Forms之OnElementPropertyChanged那些事
- 两台Linux主机通信(服务器客户端搭建)
- SELinux深入理解
- Linux2.6.38内核启动流程分析
- 查看当前ubuntu版本号
- linux下tar的用法
- Linux内核同步方法
- 用@property声明的NSString(或NSArray,NSDictionary)经常使用copy关键字,为什么?如果改用strong关键字,可能造成什么问题?
- 编译通过的U-boot和使用的arm-linux-gcc编译器
- 手工运行 sudo dpkg --configure -a 解决此问题