前言：在一个公司工作两年了，没有对工作进行和记录和总结（老毛病一直未改），必须到总结的时候。
在公司的角色：
这家公司是我的第三个公司（有一个公司是实习），以研发工程师身份入职，期间身兼研发，应用运维，软件维护，系统三线支持。后期由于产品规模的扩大（上线机器达到5000台），以应用运维，软件维护，系统三线支持为主。以上是公司对我的定位。
应用运维的工作常态：
7*24小时，电脑不离身（包括下班后，节假日）
下面介绍我在具体角色的工作职责：
一、应用运维
1、产品上线准备（包括环境部署，数据准备，数据导入）
2、产品发布（对新版本的应用程序和环境进行需求确认，测试和再验证，确定无误后制定升级计划并实施），更新最终确定的需求说明文档
3、负责测试平台、准生产平台与生产平台一致性部署和维护等工作；
4、上线后的推广培训以及维护，处理和跟进
一）应用系统突发事件，问题和服务请求的响应、定位、跟踪、解决，及统计汇总分析和管理
二）问题类别有故障、请求、咨询、新需求、投诉，如果归类为新需求，反馈给项目经理，需求分析师，开发团队
5、负责应用系统可用性与性能监控（包括自动监控与人工监控），确保系统的稳定运行，确保客户业务不受影响
6、运维知识库更新维护
包括版本更新管理，需求文档更新，问题记录及其解决方案文档更新
7、研究运维相关技术
8、完成领导交办的其他工作。
对运维的理解：
运维也是一种服务，目的强调改善
运维过程中，最喜欢做的就是故障处理，看着故障一个个解决，好开心o(^▽^)o
特别要对上述4说明下，因为故障处理多了，就要总结，不然时间都花在重复性工作上。
事件的类型，我们可以分为：故障、请求、咨询、新需求、投诉，这样可以跨项目统计，每个周期内的
每一个事件类型有多少。比如事件的分类：我们可以分为软件、硬件、网络、数据库、接口、业务。
需要有一个精确的记录和定位，以便让你知道哪个地方出了多少问题，在项目层面可以提供精确的数据来做改进（哪一个模块是问题最多的），在管理层面，记录的信息会告诉你哪一类是我们运维的薄弱环节（如果硬盘的故障比重较大，我们可能换供应商，或者提升运维人员在硬盘维修能力）
需要时间资源的记录：这一部份的数据采集是最为困难，也是最有价值的，它与上面的信息交互分析，可以知道哪一类事件花去我们最多的时间资源（CMDB），可以知道我们故障的平均处理时长是多少（事件分类），还可以知道新需求会花去我们多少时间资源（事件类型），除此之外，还有基于员工的绩效分析以及运维结算的数据统计都是需要基于此部份的信息的。