it公司实习心得体会精彩范文(2)
it公司实习心得体会篇四
看到了很多同学问到各银行的待遇以及IT部门的发展之类的话题，想到了自己银行的情况。
1、加班非常多。机房是24小时开放的，每天都有人值夜班。我所在的地区我们分行只有800人不到，IT部门就只有6、7个人。他们每天除了正常的工作之外还要应对各种培训、学习。银行因为白天要对外营业，所以每次培训之类都是在晚上和周末，而且不是800人一起培训，而是今天这个培训，明天那个培训。这个工作量是非常大的。而且银行加班基本是没有加班工资的。因为国家不允许这种量的加班。
2、薪水问题。大家都说银行薪水好。那是因为大家看到的只是薪水好的部门。我现在在银行做贷款，属于一线营销岗位，薪水自然还不错。但如果你不是做营销而是后台部门比如IT，那你只能拿到基本工资和平均奖金，这个数字看起来就没那么有吸引力了。除非你能当老总。可这个部门不像营业网点，一个地区可以几十个网点，这个IT部门基本上一个地区就一个，也就是说一个地区就一个老总，这个老总又不像别的岗位可以横向调动，在银行里做IT你就只能做IT，不可能调你去做什么公司业务，所以我个人认为升迁的机会也比较小。但如果你是去总行的信息技术部搞些个产品研发之类也就不说了，那肯定是非常好的，但这样的部门基本也不可能要一个刚毕业的学生。
3、银行的各项任务是很重的，而且可能看起来都非常不人性。不要以为你在IT部门就不可能有任务。我们讲究的是全民皆兵。
以上只是我个人的一些看法，给一些纯粹是为了拿高薪找安逸的同学一个提醒。
当然银行也有银行的好。比如：
1、如果你做的很好，这里指的是营销，比如你能带来大量存款，你有很广的客户资源，那你的薪水会非常高而且不受职务限制。
2、福利待遇非常好。我们银行给我们解决了所有的后顾之忧，你只要好好工作，其他什么都不用你操心，我们有非常低的行员贷款利率，你买房子就不需要担心。我们是按照最高比例来购买各种保险、公积金之类。即使你生病了，你住院了，不但医药费都能报销，算下来你每天还能赚几百块钱，可能比上班都高。
总之吧，银行就是个数字说话的地方。想在这做IT可能你永远都做不到最顶端。但也有他的好。大家各自考虑吧，只是就个人的感受给大家的建议。相比较之下我认为我所在的招商银行是最有潜力的银行，发展非常快，企业文化非常好。工、农、中、建四大行规模非常大，但因为是老行也有很多弊端，国企思想比较严重，论资排辈。交行的特色在于他是股份制银行中最大的，个人理财比较突出。民生是最变态的，只要你有业绩，第二天就是行长，只要你没有业绩，马上从行长变成行员。中信是业内口杯最差的，到处乱市场，很受同业鄙视。华夏的最大特点在于他的公司业务。一般越小的行可能待遇越好，机会也越多，因为他在发展。
其实就个人而言，我觉得银行里做IT就像是当年我们来北邮，大家都知道北邮非常好IT业的最高学府。可我们当时因为种种原因到了北邮的语言学院学外语。并不是说语言学院不好，我们在这里也学到了很多东西。但这里的主流是IT，语言院再发展可能也比不了北京外国语。就是说你是到一个非常好的学校一个非主流的专业，还是到一个一般学校的主流专业，你可以自己考虑。
it公司实习心得体会篇五
本人从事IT行业基本分为四个阶段，第一个阶段是学习阶段，第二个阶段是实践阶段，第三个阶段是管理阶段，第四个阶段是形成管理体系的阶段。时光如流水，一晃，从事IT行业已经有12年，回想这些年自己走过的路，不禁感慨万千。借这个机会对过去的工作进行总结，也与同仁们进行交流。
记得20xx年的时候，我正在学校读研究生，那是IT业正火的时候。当时我的研究生导师跟中国石化合作开发加油站管理系统，我有幸参与到这个项目的开发中。当时很兴奋，一是可以学习计算机知识，二是能够真正的参与到真正的IT行业中。因此我工作非常努力，每天工作到很晚，甚至周末也不休息，全心全意地参与到这个项目中。我的工作是开发项目中两个核心的工作，油品的库存管理和IC卡信息管理，这个项目周期很长，差不多花了两年的时间，期间改版了两次，最后终于成功上线。现在回想起来，当时我基本上没有项目管理的概念，连需求分析、系统设计、集成测试、上线试运行这些概念都不了解，以为项目就是客户提出需求，把功能实现就行了，也没有考虑系统的可维护性和稳定性，以及升级的需要，因此走了很多弯路。通过这个项目，我最大的收获就是有了实际的项目开发经验，对如何开发一个IT项目有了实际的了解，但是基本上还是个菜鸟，项目管理的理论还没有形成，甚至没有这种意识。
20xx年研究生毕业后，我进入了深圳一家IT公司，参与基金公司投资交易系统的开发工作，该项目的特点是需求方比较多，需要跟基金公司的五个核心部门进行需求的收集整理，现在我们知道干系人管理的重要性，但在当时，我还没有这种概念，就是感觉用户的需求很难整理，因为用户是从使用方的角度来提出问题，而我是从计算机系统的角度上考虑问题，将用户的需求转换为系统实现则非常复杂，甚至一些特殊原因造成各部门提出的需求不统一甚至是相互冲突的。因为没有项目管理的理论经验，不知道如何进行干系人管理，我常常感觉很苦恼，觉得用户的需求不合理，经常跟用户造成冲突。经过多方努力，该系统终于开发完毕，但因为系统非常复杂，而且对业务影响极大，因此该系统采用并行使用的方式进行试运行，经过试运行发现了系统设计上及功能上的缺陷，经过二次升级，系统终于上线成功。经过这个项目，我意识到了干系人对于项目成功的重要性，对项目管理也有了整体的概念，开始形成自己对项目管理的一些经验。
20xx年，因公司转型，我进入到一家地产公司，参与地产项目的管理工作。因为有几年的实际工作经验，又成功开发过项目，我开始独立负责项目的开发与管理。当时我带领6个新人进行系统的开发与管理工作，从需求的分析、系统设计、详细设计、系统开发、系统测试、上线试运行到系统上线，对各个阶段进行管理，成功地开发了几个大的项目，对于项目的掌控能力和项目管理的实际经验也愈加成熟。但随着项目管理经验的丰富，我发现自己进入了瓶颈，因为缺少整体的项目管理理论的支持，项目管理经验无法获得更大的提升，我只是经验越来越丰富，而没有真正的形成自己一套行之有效的项目管理方法。
终于，在20xx年，我了解到PMP在中国的发展，感觉到自己终于找到了方向，即从理论上充实自己。我参加了PMP培训班，在学习的过程中，我感觉自己找到了一盏明灯，多年来的困惑终于找到了答案。五大过程组，九大知识领域，这些理论让我感觉耳目一新，PMP从总体上对项目管理理论进行了解释，使我的眼界有了大的提高。我明白了什么是真正的项目管理，以前自己是在黑暗中摸索，现在终于找到了前进的方向。我觉得学习PMP最大的收获就是有了完整的理论基础，而不是只靠经验。须知经验只是基于过去的项目经历得来的，并不能解决所有的问题，以前是知其然而不知其所以然，而有了PMP的理论基础才是知其所以然，以后不管遇到什么样的问题，都可以通过PMP的理论基础来解决问题。
对于项目管理，只靠自己的努力是不够的，还要善于总结，善于学习，一定要有PMP的项目管理理论作为指导，才能少走弯路，早日成功。回想自己的项目管理经历，几多汗水，几多收获，酸甜苦辣，万般滋味在心头。不管怎样，十多年间，我从一个什么都不知道的小菜鸟，成长为今天的项目总监，回想自己走过的路，项目管理理论的确很重要。谨以此文对我走过的项目管理之路作为总结，也希望各位同行早日成功。
it公司实习心得体会篇六
IT运维工作直接关系到应用系统运行的正常稳定，但运维工作纷繁复杂，正规化、系统化相对比较弱，如何改变这种现状?从众多的运维工作者的成功失败中进行经验总结，并提升为运维规则，是提高运维水平，保障应用系统正常稳定运行的有效途径。
笔者通过自己的多年运维经验，总结出以下必须遵守的基本运维规则，可以大大减少缺乏经验的运维人员因为自身失误导致系统出故障的可能性。
一、系统变更、升级应先在同样的环境测试通过，执行前应有经过验证的回退预案
运维是一门经验的学科、是一门试错的学科。没有做过的东西、总是会给你出意想不到的难题，因此变更前，一定要在相同或者相似运行环境下进行测试，通过后才能在正式环境下执行变更。同时应准备好变更失败的回退预案，比如，做好系统备份、数据库备份、配置备份，固化变更前的运行现场，让变更有回头的机会。
二、对破坏性的操作要先确认符合预定方案，然后谨慎执行 什么是破坏性的操作?
比如：
对MSSQLServer，执行update操作，因为不需要commit，所以特别容易忽视也特别危险，还有delete、drop等操作更不用说。 对 Oracle 而言：truncate table_name、delete table_name、drop table_name，这些语句执行起来轻松简单也惬意极了、但记住!即便数据可被回滚、代价也是非常大!
对 Linux 而言，rm -r 所有当前及其子目录的所有数据都将被删除。经历过这种故障的人、大多会给 rm 上个别名
A liasrm='rm -i'
同理、cp 和 mv 也可以有同样的选项：
aliascp='cp -i'
alias mv='mv -i'
对window而言，shift+del文件或者目录 对任何系统而言，无备份直接修改文件等
三、备份并验证备份的有效性
不管是硬件还是软件总有意外崩溃的时候，怎么办?备份!!!备份的学问很大、按照不同的维度可以分：冷备和热备、实时和非实时、物理和逻辑、全备增量备。
备份有了、可以高忱无忧了吗?不行!尚须验证备份的有效性。一个总有那么几次、备份无法保证 100% 恢复，简单的验证就是找个空库恢复出来。
四、对生产环境永保敬畏之心
这是避免应用系统发生故障的一条铁规，也是被开发、运维人员容易忽视的地方。要坚决杜绝直接在生产环境做开发、测试和bug修复，这些操作只能在开发和测试环境做，否则一旦出事，将欲哭无泪。
五、交接和休假最容易出故障
接手别人的工作要一而再，再而三的确认变更方案，请教人并不见得就是能力不行的表现;
休假前最好各种可以做好的事情，最好能够准备一份文档，指明在什么情况下怎么做和联系哪些人;
在别人放假的时候接手工作，“能拖则拖”，实在需要执行：必须不厌其烦的跟原系统管理人员确认各个操作细节。
六、一定要有监控手段和报警措施
运维人员赖于生存的工具就是报警和监控。
报警可以让你及时知道系统出现了什么异常、以便及时跟进、把故障扼杀于摇篮;
监控可以让你了解系统的历史性能信息、以历为鉴、可以知兴替、早做优化。 报警和监控是衣宽带水的好兄弟、相铺相成、互相促进。
七、使用自动切换技术需谨慎
为了保障数据库安全，往往会使用HA或者RAC之类的技术，但是这类技术能否真正在关键时刻起作用，则是需要经过反复验证和确认的。并不是按照文档要求做好了就够的，很多意外因素或者系统因素会导致自动切换技术并不能如期发挥作用。如果到事后才发现这一点，将悔之晚矣。
八、要有偏执狂的精神，方案要检查，检查，再检查 有这么一个人：
① 他在做一个变更的时候，会先提前一两周发送邮件并电话手机通知相关人
② 在测试机上写好脚本，召集大家 review 操作步骤和脚本
③ 测试完成以后拷贝到生产环境
④ 登录对应机器，“打开，关闭，打开，关闭”该脚本
⑤ 跟相关人员再次确认执行的操作，顺序，时间点，可能的影响和回滚是否都准备好了
⑥ 执行前还要退出这个机器，然后再登录进去，“打开，关闭”脚本
⑦ 最后才在后台运行脚本，同时在另外一个窗口登录着，随时ps和查看结果输出
期间姿势端正，呼吸急促而均匀，眼神凝重。操作的人不觉得累，倒是一边观摩的人很累。
九、简单即是美 我们总是面临各种诱惑：新的系统架构，新的更智能的命令和工具，最新的硬件平台，功能更全的HA软件...你可以在线下安装，测试，怎么做都行。但是如果想要在生产环境下使用起来、请三思!!
能够使用系统内置命令的话，就不用考虑其他要专门下载安装的软件了 脚本本身就能完成的功能，就没有必要专门找一个功能丰富的软件来做 Linux本身自带的字符界面比那些复杂的图形界面要简洁方便
如果能做到坚持这九条铁规，你的应用系统就能长久稳定运行了。
猜你喜欢：
