[it述职报告怎么写 范文]it业述职报告范文【三篇】

【#述职报告# 导语】述职报告是干部工作业绩考核、评价、晋升的重要依据，述职者一定要实事求是、真实客观地陈述，力求全面、真实、准确地反映述职者在所在岗位职责的情况。对成绩和不足，既不要夸大，也不要缩小。---以下是®文档大全网为您提供的文章，欢迎阅读。

　　【篇一】

　　大家好，我是XXX项目组的XXX，我于2011年7月进入公司做JAVA程序开发，至今已近快一年时间了。初来公司，曾经很担心不知该怎么与人共处，该如何做好工作;但是公司融洽的工作氛围、团结向上的企业文化让我较快适应了公司的工作环境。在本部的工作中，我一直严格要求自己，认真及时做好领导布置的每一项任务。不懂的问题虚心向同事请教，不断提高充实自己，希望可以为公司做出更大的贡献。

　　当然，刚做这个项目的时候，难免出现一些小差小错需领导指正;但前事之鉴，后事之师，这些经历也让我不断成熟，在处理各种问题时考虑得更全面，杜绝类似失误的发生。在此，我要特地感谢部门的领导和同事对我的指引和帮助，感谢他们对我工作中出现的失误的提醒和指正。总结经验是一个人迅速成长的有利催化剂，为了更快地成为一名优秀的员工，现将我20xx年上半年的学习、工作情况总结如下：

　　20xx年初时，我们进销存项目通过了一期客户验收。但是，随着客户业务的变化，项目需要做很大的改动和调整。现进销存系统进入了二期的设计开发阶段。

　　初入公司的时候，我只负责财务模块的存货核算开发工作。随着公司人员的变动，现在我负责财务管理整个模块的开发工作。很明显的能感觉的身上的压力越来越大，也许是因为我的个性使然吧，越挫越勇，迎难而上。不断的学习财务业务知识和本系统框架，现基本了解掌握了财务的整个业务逻辑及业务流程。因为没有参与一期的原型、需求、设计、数据库等文档的设计。

　　在开发过程中发现，有好多原型、需求文档、设计文档，只知其然，不知其所以然。总结一期经验，避免二期开发中遇到同样的问题和困难。从原型设计、谈二期需求、整理需求文档、数据库设计、开发，*负责到底。这样对业务逻辑及业务流程有了更深的理解。从“我问”，到“我讲”，有了很大的个人提高。提高软件知识和技术只是问题的表面，本质是要提高自己认识问题、分析问题、解决问题的思想高度。在能胜任工作的基础上，立即去涉猎其它领域的专业知识，丰富自己的知识体系、提高自己的综合素质。

　　我相信付出肯定会有收获，在我们的努力下，进销存系统一定会给客户及公司一个满意的答案。

　　在这一年里，我看到公司的迅速发展，各项制度的不断完善，我很庆幸我是公司的一员，我会用谦虚的态度和饱满的热情做好我的本职工作，为公司创造价值，同公司一起创造美好的未来。

　　【篇二】

　　先自我简介一下，本人从事asp.net开发进一年，09届毕业生，XX年11月开始上班，之前做asp，XX年2月后开始做asp.net，由于公司转型，现在带十几个人在一起搞asp.net开发，主要是关于准金融行业的行业管理软件。年度总结在会议上也写了，但仅限于对于工作总结及XX年工作计划，自我总结较少，因此今天专门做下自我的年度总结，主要从技术、管理、人生上面谈谈这一年的收获，前辈路过欢迎多多指正。

　　技术

　　我在学校里学的是电气自动化，程序基础仅限于c基础课程的一些知识，后来由vb、html转向asp，在asp上花费了不少时间，对asp比较熟悉，后来由于公司业务需要，将开发平台转向asp.net，开始对asp.net不是很感冒，以为就是asp的一点扩展(那时还不知道三层架构，数据数据访问全在页面里——!)，后来招来几个北大青鸟的过来终于意识到asp.net的强大之处，经过个人的努力已经逐步掌握了asp.net，现在层次上只能讲个人觉得是入门而已，原因是多方面的，待会儿会讲到。

　　相信从面向过程转向面向对象的同学都有一种感觉：面向对象开始真的有点别扭，涉及到属性，尤其是类之间的各种关系，那时老想用面向过程传递参数多方面啊。于是老在想对象这种东西，从概念中跳中来，以自己的方式去理解才逐渐体会到页面对象的精华来，分层次展现、分级别访问、封装对象之间各种关系逐渐真正理解了，尤其是对象之间的关系，如对象a与对象b两者之间的关系，有些需要完全公开，有些需要隐藏，有些需要通过第三方传递，有些需要给自己的下级可见，有些需要让下级去完成具体操作——这不是现实的实际模型吗?应该这么理解，面向对象来源于现实，它不是一种凭空空想出来的理论，这些对象之间的关系可以将其还原为父子、夫妻、领导下属、同事、朋友之间的关系。相比之下，页面过程往往像是一股脑全部推给用户使用，其中的数据与数据访问方法层次不清晰，在模拟现实上它与面向对象相比更易于入门理解，实质上难于准确直接地表述。

　　面向对象上另一方面是它的设计模式，在之前的面向过程中对这个设计模式并没有清晰地提出来，面向过程优秀的代码要求高内聚低耦合，从个人的理解上，这仅是对软件开发方法“技”上理论总结;设计模式是达到了“道”的层次，因为它从更大的方向、更抽象的层次来去表述具体的代码模块之间的关系，可以认为设计模式是完全从实际的应用来不断总结得来的经验，之间并没有这种术语，但相信前人肯定也使用到这种思想，它从实际应用于来，当然要应用于实际工作中，认真思考不断总结每个人都会有自己的“设计模式”，可以借鉴前人的思想来去提升自己，不可去为“设计模式”而设计模式。

　　具体到asp.net的实现模型中，真正理解它的机制与方法也就不难理解，记住b/s中离不开post或get，所有的autopostback、selectedindexchanged……都是去调用form传值，加上runat=server的服务器控件打开它生成的源文件也是普通的html标签，微软的让软件开发更容易的思路是很好的，时代在前进，很多年前你使用c写出mis证明你很牛，很多年之后你不在使用c去写“学生管理系统”、“图书馆管理系统”那只能说明你的脑子少一根筋，开发语言都有长处与不足的地方，因为它们适用的场合不同，类似不能拿匕首去跟炮弹比，也不能拿c与php比，程序员都有一种偏执的心理，但一点要记住，你面对的用户才有最终发言权，程序能不能满足需要，易用性、稳定性、成本才是应当首先放到重要位置来去谈的。

　　管理

　　最开始担任管理一职时开发团队加我在内只有四个人，那时只是抱着接受挑战的心理去做管理，加上我本人比较重感情，团队之间关系相处都不错，但严重的问题逐渐显露出来：工作的随意性、团队精神薄弱、工作方式蛮干，印象深刻的是有几个开始项目不能完工，于是最后天天加班，一直做到早上6点，睡一会7点半接着上班，几个同事都是年龄差不多的小伙子，干劲十足。后来随着时间的推进，问题越来越摆在眼前：项目迟迟不能完工，又由于公司待遇方面让新员工感觉不值得，于是形成了老板抱怨员工也抱怨的状况，我在中间两点都要去“消火”，这期间是我们部门相对最累的时间但也是相对感觉最充实的时候，后来，之前的员工跟我说“再也找不到那种感觉了”，这是我能想像的。这期间主要是老总对我十分信任，工作上主要是管理方法上对我指点了不少。后来我逐步体会到，管理应该是“大家定规则去遵守”，而不应该是“人管人”。

　　人管人很容易陷入一个误区：领导去时时刻刻关注每个员工，这样最后往往后造成员工对领导的敷衍了事，管理松了员工会责任下下降，管理紧了造成员工与领导关系紧张，另一方面领导时间精力有限必然耗费大量的精力在日常的监督中而不能投入到全局的管理中。

　　于是“定制度-定分工-定进度”，明确日常所有的规章制度，这期间除了公司主要的工作规章制度外其他的日常工作纪律、日常管理等规章制度都是我本人制订，然后征求大家意见最后去贯彻执行。中间也遇到了不少问题，比如开始我们内部是允许使用qq的，后来员工用qq闲聊的时间增多，大大影响了工作效率，最后决心禁止，开始阻力较大(貌似程序员都喜欢挂上几个qq去到群里搞个群主，虽然群里大多都是菜鸟)，最后多次开会，逐个谈话，阐明道理，形势逐渐好转。

　　项目分工上针对技术水平明确分工，制订项目开发计划，由于开始技术都不是很成熟，不少时间我这边强势要求，使用野蛮方法，完不成加班——我陪着加班，这段时间能感觉到员工对我稍有怨言但总体还是认可的。

　　这期间公司新招人员，人员的增多更使我意识到团队管理的重要性，这期间版本控制、编码规范、文档管理、bug管理等诸多问题都得到一一解决，技术水平上主要是我个人利用空余时间学习新知识充电，然后展开各种培训，主要是photoshop、css、js、sql等方面，培训一方面提升了员工的技术水平，一方面我本人在学习培训的过程中得到的最多，因为这个时候个人要求去思考的会更多，加上我本人对技术兴趣比较深厚，所以后期工作慢慢踏入良性循环。

　　待遇低、条件艰苦、工作时间长、工作压力大是团队中的难题，这方面公司在某些方面决策层有着严重的错误思想，造成技术人员对公司埋怨增多，在这方面我本人只能以劝架婆的身价去安慰身边的兄弟，因为我明白现在公司的问题与当前中国软件行业的通病一样，盲目追求利益化，不求质量，但求速度，整个社会风气造成软件行业良莠不齐发展，整个中国三四个人的开发团队组成的公司数不胜数，整个程序员阶层生存状况可想而知，疯狂加班、代码质量低下、维护成本大、稳定性差、用户体验差……。

　　当然我们本身不能去逃避这个现状，对于个人来讲任何假大空的口号都是没有意义的，程序员作为技术人员最重要的是心态，以良好的心态去面对各种问题，发现问题、解决问题，发现问题抱怨是解决不了问题的(“it民工”是我个人认为it人最没有正确的自我定位的一个称谓，试想一个人连自己都看不起自己的职业，他能做好自己的工作吗?)，最主要是解决问题。

　　我在面试员工时反复提到的三点是：工作态度、发展潜力、工作能力，由前向后排序，心态最重要，大公司大家都想削尖脑袋往里挤，但名额有限，所以广大的程序员同志绝大多数都集中在二流三流四流的软件公司，这个时候更应该做好个人职业定位。以我个人的经验，新员工选择一家公司往往最看重工资待遇跟发展潜力，程序员是一种不可以混日子的职业，工作能力很重要，但不是最主要的，工作态度是最重要的，工作态度往往跟个人的思想认识还有职业所在的环境有关，我个人的体会是绝不能太过于情绪化，情绪化无论是对工作还是对个人的发展都是不利的，就是说哪怕是明天你要辞职，你今天都要把今天要做的事情认真用心做好。

　　对于工作责任心不够的员工是尤其值得关注的，他们往往自我意识过于强烈，追求以自我为中心，很多时候伴随着工作得不到认可、工作感觉不充实不开心，我会主动找他谈话，我认识：你管理的是一个实实在在的人，他不是一台任你摆布的机器，人会有情绪往往是有心结，找到原因，多加开导，用心去关心每个成员。对于实在不适合在本团队发展的员工要做好最坏打算。程序员这个职业与现在的大学生具有一致的特征，一个是从天之骄子沦为多余人，一个是从高智商人士成为今天中国通行的”it民工“。另一方面是程序员往往年龄集中在20-25之间的男性中，情绪化、失落感、心理不成熟等一系列问题都会出现。但这个阶段的人往往也最易沟通，可塑性也较强，适当的引导、合理的方式会比野蛮的管理效果强上百倍。

　　【篇三】

　　运维工程师对一个公司来说是非常重要的岗位，它本身所覆盖的运维职责就很重要，所以，运维对其它关联工种必须非常了解熟悉：网络、系统、系统开发、存储，安全,DB等。作为一个运维工程师我认为是集合网络、系统、开发工作于一身的“复合型人才”，就如有些公司把一些合同采购都纳入了运维职责范围，还有如IDC网络规划也纳入运维职责。

　　一.运维工程师岗位职责

　　1、参与设计、审核、优化公司IT系统以及各应用系统的体系架构;

　　2、全面负责公司运维项目的系统升级、扩容需求与资源落实，配合开发需求，测试、调整运维平台;

　　3、负责网络以及服务器的网络设置、维护和优化、网络的安全监控、系统性能管理和优化、网络性能管理和优化;

　　4、建立面向开发部门，业务部门的服务流程和服务标准;

　　5、负责IT运维相关流程的规划、设计、推行、实施和持续改进;

　　6、响应及解决客户的技术要求、疑问以及系统使用过程中遇到的各种问题;

　　7、负责日常网络及各子系统管理维护。

　　8、负责设计并部署相关应用平台，并提出平台的实施、运行报告。

　　9、负责配合开发搭建测试平台，协助开发设计、推行、实施和持续改进。

　　10、负责相关故障、疑难问题排查处理，编制汇总故障、问题，定期提交汇总报告。

　　11、负责网络监控和应急反应，以确保网络系统有7*24小时的持续运作能力。

　　12、负责日常系统维护，及监控，提供IT软硬件方面的服务和支持，保证系统的稳定。

　　13、负责服务过程中问题现象和处理方案的收集撰写，形成知识库，并对知识库进行维护更新;

　　14、及时反馈技术处理过程中的异常情况，及时向部门负责人、服务开发PM、客户经理等相关人员报警;同时，主动协调资源推动问题解决;

　　15、定期对所有服务问题进行分析，并对服务效率有影响的问题提供反馈意见，提升服务支持团队专业度;

　　二.怎样才算是一个合格的运维工程师

　　1、保证服务达到要求的线上标准，如99.9%;保证线上稳定，这是运维工程师的基本责职所在。

　　2、不断的提升应用的可靠性与健壮性、性能优化、安全提升;这方面非常考验主动性和创新思维。

　　3、网站各层面监控、统计的覆盖度，软件、硬件、运行状态，能监控的都需要监控统计，避免监控死角、并能实时了解应用的运转情况。

　　4、通过创新思维解决运维效率问题;目前各公司大部份运维主要工作还是依赖人工操作干预，需要尽可能的解放双手。

　　5、运维知识的积累与沉淀、文档的完备性，运维是一个经验性非常强的岗位，好的经验与陷阱都需积累下来，避免重复性范错。

　　6、计划性和执行力;工作有计划，计划后想法设法达到目标，不找借口。

　　7、自动化运维;能对日常机械化工作进行提炼、设计并开发成工具、系统，能让系统自动完成的尽量依靠系统;让大家更多的时间用于思考、创新思维、做自已喜欢的事情。以上只是技术上的一些层面，当然个人意识也是很重要的。

　　三.运维管理注意事项

　　1、配置管理

　　(1)it资产配置管理：对it资产生命周期进行管理，包括分类统计、预购、选购审核、转移审核、报废审核，保证配置管理正确率达标;

　　(2)建设案例库：累积和提炼工程师的事件处理经验制作成案例，并持续丰富运维案例库供查询，案例覆盖已知事件的比率达标，不断提高运维工程师工作效率;

　　(3)it系统配置信息管理：定期更新网络及应用系统描述信息及技术支持信息配置，保证最新;将配置文档上传至服务器端，方便团队其他运维人员进行查看和操作。

　　2、监控

　　主要包括故障监控和性能、流量、负载等状态监控，这些监控关系到集群的健康运行，及潜在问题的及时发现与干预;

　　(1)、服务故障、状态监控：主要是对服务器自身、上层应用、关联服务数据交互监控;例如针对前端webserver，我们就可以有很多种类型的监控，像zabbix，nagios，cacti等监控程序。

　　(2)、其它就是集群状态类的监控或统计，为我们合理管理调优集群提供数据参考、包括服务瓶颈、性能问题、异常流量、攻击等问题。

　　3、故障管理

　　(1)、硬件故障问题;对于成百上千或上万机器的N多集群，服务器死机、硬件故障概率是非常大的，几乎每时每刻都有服务硬件问题，死机、硬盘损坏、电源、内存、交换机。针对这种情况，我们在设计网站架构时需要充分考虑到这些问题，并将其视为常态;更多的依靠应用的冗余机制来规避这种风险，给系统工程师足够宽裕的处理时间。(如google不是号称同时死800台机器，服务不会受到任何影响吗);这就是考验运维工程师及网站架构师功能的地方了，好的设计能达到google所描述自恢复能力，如gfs，糟糕的设计那就是一台服务器的死机可能会造成大面积服务的连锁故障反映，直接对用户拒绝响应。

　　(2)、应用故障问题;可能是某一bug被触发、或某一性能阀值被超越、攻击等情况不一而定，但重要的一点，是要有对这些问题的预防性措施，不能想当然，它不会出问题，如真出问题了，如何应对?这需要运维工程师平时做足功夫，包括应急响应速度、故障处理的科学性、备用方案的有效等。

　　4、问题管理

　　对事件进行统计分析，找出疑难、重复发生的事件，纳入问题管理流程，分析问题产生的根本原因，确定可能解决的方案，需要修改网络或应用系统配置时提交变更申请触发变更管理流程。

　　5、安全管理

　　(1)、操作人员随时监控中心设备运行状况，发现异常情况应立即按照应急预案规程进行操作，并及时上报和详细记录。

　　(2)、未经批准，不得在机房设备上随意编写、修改、更换各类软件系统及更改设备参数配置;

　　(3)、服务器系统的维护、增删、配置的更改，必须按规定详细记入相关记录，并对各类记录和档案整理存档。

　　(4)、机房工作人员应恪守保密制度，不得擅自泄露信息资料与数据。

　　(5)、严禁在机房计算机设备上做与工作无关的事情(如聊天、玩游戏)，对外来存储设备(如U盘、移动硬盘等)，做到先杀病毒后使用。

　　(6)、机房严禁乱拉接电源，应不定期对机房内设置的消防器材、烟雾报警、恒温设备进行检查，保障机房安全。

　　6、自动化运维

　　自动化：简而言之，就是将我们日常手动进行的一些工作通过工具，系统自动来完成，解放我们的双手及枯燥的重复性劳动，例如：没有工具前，我们安装系统需要一台一台*机安装，如2000台，可能需要10人/10天，搞烂N张光盘，人力成本更大，而现在通过自动化工具，只需几个简单命令就能搞定、还有如机器人类程序，自动完成以往每天人工干预的工作，使其自动完成、汇报结果，并具备一定的专家系统能力，能做一些简单的是/非判断、优化选择等，这些好处非常明显不再多说，

　　资料共享平台

　　应该说，自动化运维是运维工程师职业化的一个追求，利已利公，虽然这是一个异常艰巨的任务：不断变更的业务、不规范化的应用设计、开发模式、网络架构变更、IDC变更、规范变动等因素，都可能会对现有自动化系统产生影响，所以需要模块化、接口化、变因参数化等因此，自动化相关工作，是运维工程师的核心重点工作之一，也是价值的体现。

　　四、总结

　　综上所述，做一个好的运维工程师，除了具备良好的综合技能水平，还要有一个负责任的工作态度，这也是优秀运维工程师具备的素质。因为对于运维工程师而言，每一次故障的发生都不是小事，很可能会影响公司线上业务的稳定性，甚至直接导致公司的经济损失，所以我认为对待工作中发生的故障以及事件要秉着一个“小事件，大处理”的原则，将发生的故障扼杀到摇篮里，慢慢地积累故障处理经验，这样当真正的大事件来临时，我们可以采取有效的措施及时应对。除了处理好发生的故障事件，我觉得运维工程师还应具备可预见性，故障随时可能发生，如何防患于未然，这将是对我们做好运维工作的一个考验。古人云：“不积跬步无以至千里，不积小流无以成江海”运维之路就是由一次次故障事件中拼接出来的，作为其中的一份子，任重而道远!

本文来源：https://www.wddqw.com/6LP5.html