登录系统或者通过监控报警平台查看系统运转的负载
IO，内存使用率，CPU使用率等进行定期分析和优化。
陈湛翀，从事运维工作
在我面试了一些运维职位的同学以后，我觉得在中国很大一部分运维的同学都是每天过着我以下要提到的，我最不喜欢的最典型的一天。
我最不喜欢的一天：
早上一来到公司，就被一个跑过来的同事打断：他有一个需求。其他的同事在IM、邮件和电话中也分别提出了他们的需求。没办法，只能默默地把这些需求记在todo list上。
刚坐下，临时被拉去开一次会，同事说要怎样怎样协助他。
刚回来，发现10分钟后有一个面试。
面试回来，发现10分钟后有一个计划中的会议。
会议回来，产品功能测试完毕，要协助上线操作。
上线过程没有标准化，生产环境出错，紧急回滚。
抓来这次上线相关人员，讨论为何会出现这样的事故，日后如何规避。
回来后，再次准备上线，这次上线过程全程跟进。
终于正常上线完成了。
噢，不。只是功能上线完成，原来还有一个很大的性能问题。继续救火。
调整参数，性能调优，服务器负载终于下去了。
看一下时间，已经差不多是下班的时间了。
对着一直在增长的todo list，一脸的茫然。
以上略夸张，但是各种千奇百怪的中断确实很可怕。各类中断还有上下文切换的。很多人就这样埋没在中断中了。个人认为一个运维最应该的一天工作时间安排：
20%的时间——处理紧急重要的事情。
80%的时间——开展重要不紧急的事情的工作。
紧急重要很容易理解，其实就是救火类工作。
重要不紧急的工作，才是最能体现运维的价值的工作。监控系统，这个是一个大话题。除了被动地监控各类服务的正常与否，还有主动开发各类协助系统分析的系统，并对整个系统的未来有规划性。
性能调优是我最喜欢的一个方面。发现性能瓶颈和解决性能问题，我都很喜欢。
开发工具型系统是提高自己和团队内所有人的工作效率的一种途径，尤其是可以快速解决那些中断的工具。
学习——这个是最重要的。运维涉及的知识面非常广，不断学习才能顺利快速解决以上各类问题，不断尝试不断经历才有足够的经验遇神杀神，遇佛杀佛。
一天一天，做好重要不紧急的工作，才能令到运维工作更有效率、整个系统更稳定、未来的发展更具有预见性。
十力，淘宝运维工程师
正常的一天，8点半起床，9点半到公司开始一天的工作。
1）看看昨天的超时报表，看看那个系统超时比较多。
2）从监控图中查查超时比较集中的机器、看看机器的基础监控、硬件有没有故障、有没有人误操作、有没有人在没有通知的情况下访问引擎等。查到原因，和开发商议解决方案和deadline，回复邮件。
陈小生，网络游戏系统运维工程师
救火：突发性故障不可避免的会产生
中断：产品、程序、QC谁都能找你，事情可能也是千奇百怪，无法一一道来
求知：你需要懂的内容可不少，包括为了“对付”上面的中断
开发：各种协助运维的系统
补漏：已经BUG，可预见性的问题、缺陷
规划：高预见性，大局观
杨渐，擅长修电脑
干了几年运维，说说感受。
早上起来打开nagios，看到一串的报警，比如日志空间不足80%，某个备份没成功，某个计划任务执行失败，某个数据库的索引建立失败，等等等等….手动全部解决大约11点。
看看昨天值班的日志,各种上线,各种下线,各种修修补补,nginx主配置里增加了14行,8个配置文件;DNS配置增加N行,两块硬盘要换,一台存储机头要换,已经下线在机房等戴尔过来换。给IDC的同事打电话确认这些乱事…
。
开发和测试说某个项目的性能要提升到20 w/小时(其实这个项目每日独立ip没超过200),编辑说让我们给他们转换几万个文章的UID,给三个部门的标题写邮件“不给项目加服务器,把转UID的任务交给dba”,然后被副总裁交去办公室说——要尽力配合其它部门,不能推来推去……。回去给值班的同事写邮件说把某个项目加2台服务器,怕被骂只能自己转UID…。这就一天结束了。Linux运维工程师的一天是如何度过的
