我对运维的认识

一转眼，毕业四年了。我一直在成都从事系统工程师一职，我对运维工作的认识。

提供一个高稳定性，可拓展，尽可能低成本的，易于开发和维护的自动化基础环境，便于我们快速部署/更新新业务。建立一套适合自己的运维基础生态系统，包括知识库管理，配置管理，监控管理，状态管理。在此基础上，保证业务持续性。

1.维持服务器相关环境稳定性

刚进公司需要学习现有文档资料，模仿公司现有的运维相关操作方式和分析解决日常问题的对策。以便于维持现有业务的稳定性

其次需要常问自己和同事为什么要这么做。

有个例子，去年我们一个项目组为客户提供了一份部署文档，仅mysql 就涉及一步步主从复制,主主切换等操作步骤。客户折腾了很久做完整个步骤发现这就是一个普通mysql高可靠性的架设方案。他们很郁闷的问:为什么不直接告诉我们，需要一个mysql高可靠性，高性能集群环境。他们对此有更简单，快捷的架构和方案。

日常工作，我们需要模仿来维持稳定性，除非特别确定或和别人讨论确认后，来提高和简化方案。

2.了解并熟悉手头工作

每个公司在运维上可能处于不同的阶段。首先需要熟悉手头工作

可能有些公司已经完成了基础环境架设，目前相关工作最多的是更新和日志分析。

那我们就需要前期把重点集中在简化更新流程，加快更新速度，提高更新质量上；并尽可能多的提供一些适合目前工作的脚本和开源工具来提高日志分析的效率，让自己有很多的时间去做下一阶段的事情

3.收集，并解决现有问题

建立运维知识库，分析并总结以往历史问题。挨个出对策。

4.完善目前运维环境薄弱环节

哪些东西可以快速脚本化

是否有系统和业务级别监控，是否监控到位

是否有状态记录系统，记录是否方便查看和比较

是否有隐患单点故障，如何解决或防范该点故障

是否有自动化部署，更新工具，备份，校验以及清理备份手段

是否有一些自动恢复的机制

5.规划和部署

根据状态记录系统返回数据，增加和减少某个节点的处理能力，形成适合自己公司的业务容量规划

比如一个基于flash的美国教育网站需要在中国拓展业务。

他可以保留美国amazon s3的所有静态资源，利用中国的CDN提供商进行内容分发。

他只需要定期更新s3和cdn内容。中国用户即可很快速的浏览站点，除了注册和登录页面使用简洁的https可能打开稍慢。

无单点业务部署，强大监控和自动恢复机制引入,允许服务发生故障，但不能影响用户正常访问。

简化研发和部署

需要运维在产品设计，研发，应用测试环节介入

比如我们的一个电子商务项目，需要在app展示s3上每天都更新的图片。运维通过s3-api-shell定期获取文件列表进行对比，然后对文件的状态进行切割处理，插入数据库。研发只需要读取数据即可。

6.创造条件，不断改进

没有条件，创造条件去替代

不断改进，

大量重复性任务，可能会经历这么几个阶段，手工执行，crontab，大量crontab,监控+大量crontab实时获取每次执行状态，部分有分布式依赖关系的复杂shell定时脚本，CI+简单的shell脚本。

Ci可以定义crontab,同时ci具有执行失败/恢复成功，自动邮件通知。

Ci可以定义不同job先后顺序，为require前提job或notice下一个job.

Ci可以通过其webconsole，轻松查看每次脚本执行的日志输出。

当我们配置从svn checkout 脚本，并定期运行，CI还可以做 运行指定版本的脚本

数据库定期备份的例子

数据库备份，为了提供可靠性和减少各种意外带来的损失，我们需要加大备份频率，但mysql备份会产生锁表。我们可以通过读写分离+双主来减少一些损失。现在的lvm卷快照，以及先进amazon快照可以实现每小时备份一次磁盘，而且性能影响很小很小。我们可以将数据库或重要的动态文件放在单独的磁盘上，利用该技术进行备份。

服务器更换也只需要挂载当前备份数据即可。

7.心得和原则

安排固定部署日期，

周五，下班以及各类节假日前尽可能减少改动甚至做到不改动，提前一天创建release 分支

每次更新需要记录更新内容，或丢入版本管理系统