忙碌的外科实习轮转结束后，就去了儿科。儿科分为儿内，儿外，一共4周时间。首先去的是儿内。第一次进入病房，觉得很干净，病床突然小了一号，看到的都是些小朋友。整个病区分为2个部分，前面的是常见疾病，比如支气管肺炎，腹泻，内分泌疾病等，还有个抢救室，里面则收治了早产儿。曾经有个2个床位房间，但收治了1个孩子居然患阿米巴痢疾（经口传播，主要表现为腹痛，腹泻，排出果酱样粪便，有腥臭味，主要流行于热带与亚热带，上海少见）。而后面的则是急淋，再障等的孩子，一般情况下，医护人员也比起内科，外科就要清净多了。儿外主要收治的是开包皮的孩子。我就看见1个孩子是车祸住院的。在儿外的时候，碰到这么两个孩子，都是开包皮的。当我一走进病房，就看见这两个孩子光溜溜的躺在床上，医生开出医嘱照光，早上的时候，靠窗的孩子晒着太阳，而旁边的小朋友晒不到，他的爸爸变把窗往一边挪了一下，看见就一个小鸡鸡晒在太阳底下。到了下午，靠窗的孩子拿着枕头遮掩着继续晒太阳，我对他说：让你爸爸给你撑把伞，伞上面挖个洞，这样其他地方都晒不到，就晒个小鸡鸡就可以了。而另外个孩子是晒不到了，他爸爸边跑到护士台说：护士小姐，什么时候来烤小鸡鸡啊。给我印象深的是一个仅3岁还裹着尿片的小男孩。男孩很在本科室实习期间，我能严格遵守科室的各项规章制度，不迟到，不早退。对于各项操作能独立的完成。在这个科室实习期间我上过夜班。我清楚的知道夜班的责任，也知道上夜班的辛苦。上夜班虽然没做什么，但是人还是会觉得累。外科手术病人相对较多，也就学到了术前术后的相关知识。术前准备有心理疏导和肠道准备、饮食指导。

术后生命体征监测、切口观察、协助咳嗽排痰、观察输液量及输液速度、各种引流管的护理、尿管的护理、饮食护理以及术后并发症观察和护理等等。在日常工作中，就要求我们更耐心地去与她们交流与沟通，只有这样，才能更好地提高护理质量，让病人信任我们工作。有时间还要宣教病人的家属如何照顾病人对于术后的病人要时刻观察他的生命体征。每天我们都要不停的在各个病房中穿梭，以便了解病人的病情变化，早发现问题，早解决。在实习过程中’我严格遵守医院规章制度’认真履行实习护士职责’以马克思列宁主义，毛泽东思想’邓小平理论为指导’严格要求自己尊敬师长’团结同学’关心病人’不迟到’不早退’踏实工作’努力做到护理工作规范化’技能服务优质化’基础护理灵活化’爱心活动经常化’将理论与实践相结合’并做到理论学习有计划’有重点’护理工作有措施’有记录’实习期间’始终以爱心’细心’耐心为基本’努力做到眼勤’手勤’脚勤’嘴勤’想病人之所想’急病人之所急’全心全意为患者提供优质服务’树立了良好的医德医风。通过6周的实习，本人理论水平和实践水平都有所提高，在今后的工作中，我将继续努力，牢记护士职责，不断加强思想学习与业务学习，全面提高自身综合水平，为患者提供优质服务。我希望在以后得学习期间不断得充实自己，成为一名合格的护理工作者。

it工作心得篇3

我是20xx年初迈进郑州，放弃了计算机行业，毅然决然选择了销售（业务），起初志向是想能够锻炼自己能够独立事业的轨道，怀着勇于挑战自我、荣辱不惊的态度去做事！！！面对困难挫折、委屈打击、孤独无助我偷哭了很多个夜晚，并不向谁求助，而是寻找解决的方法咬牙挺过去！一切地一切都不算什么，令我痛心得是没有人真正能够读懂关心我。

我带着一脸茫然进入市场部，说实话，进市场部大大超出了我的意料之外。起初，我怀疑自己，并不是怀疑自己的能力，而是怀疑自己的毅力。因为我知道，市场部是所有部门中最忙、最累、最辛苦的一个。我生怕自己不能做好这份工作，怕自己会偷懒。时刻提醒自己：我可以不做这份工作，但既然做了，就一定要做好。一共做了三个行业，都是没有目的方向的去工作，就好像是无头苍蝇乱撞，寻找点去试验竞争，挑战一种极限！每个转折都是有原因的，并不是我没有坚持，是有太多的无奈！

深知自己是一个很情绪化的人，有着两面性：表面刚硬、内心脆弱。在看了李强的演讲后，让我有着很深的感触，也领悟到了自己很多的缺陷：任性、倔、心高气傲、自以为是、脾气语气刚烈，聪明反对聪明误，不顾及别人的感受，独断专行！人的一生一共有三天：昨天、今天和明天，昨天是一张发票，今天是一张钞票，明天是一张支票！所以应该将一切归零，把握今天，从新找准自己的定位与价值。告别xx年，喜庆xx年又是一个新的开始新的起点能够重新规划自己。

企业没有规矩不成方圆，应学会适应企业的文化、理念、环境，要懂得“适者生存”！！！要想走在别人的前端，就要用积极向上的心态愿意虚心请教别人：“读万卷书，不如行万里路；行万里路，不如阅人无数；阅人无数，不如明师指路”，人外有人，山外有山，要处处为师，因为静下心来，每个人一定有自己值得学习的地方，只有比别人认真，比别人付出的更多，才可能看到想要的收获。一首诗说得好：“事在人为，休言万般皆是命；静由心造，退后一步自然宽”，所谓师傅领进门，修行在个人，成败与否，都要端正自己的心态，应面对结果，自我反省（人争的是气不是理）。也深深体会到行行出状元，没有不赚钱的行业，只有不赚钱的人，没有做不成的事，只有做不成的人。也不是向往成功就可以成功，向往卓越就可以拥有卓越！成功一定有方法，失败一定有原因！要学习成功人的优点，观察失败人杜绝它的缺点！好比：没有高山就显不出平原，没有大智慧就不知道自己肤浅，没有见过坏的就不知道自己优越，没有见过好的不知道自己的缺陷，所以要善于总结自己，才能创造无限精彩！

“静坐常思已过，闲谈莫论人非，能受苦乃为志士，肯吃亏不是痴人，敬君子方显有德，怕小人不算无能，退一步天高地阔，让三分心平气和”短短一段格言，能够让我领悟到做人做事的一种风格！所以做事要先学会做人：“眼中有人，心中有事，方足大业”。在公司是一个团队，要学会在其位谋其政！学会服从聆听别人说的话，因为服从是对别人的.一种尊重，也是一种智慧；所以才会拥有行动力、执行力、思考力。这样自己才会有一个不断成长的过程。我还记得小时老师给我讲过这样一个故事《吃水不忘挖井人》，是啊，无论何时何地就要学会感恩！知恩图报，善莫大焉！众多人的动力来自两点：一是对未来不可知，不安于现状，导致一直在向前不断地拼搏、不断的努力；二是爱心存感恩是一切动力的源泉。可谓每个成就事业的人他们都是高尚的，他们是在给我们国家创造财富，万里长城今犹在，可见当年秦始皇”令我们耐人寻味啊！所以要学会换位思考，做人傻一点、蠢一点、勤奋一点，只要用心做事，自己才有收获。

心在哪里，收获就在哪里！只有走过路的人才知道什么叫路，只有走过路的人才知道路是平坦还是坎坷，只要功夫深，铁棒也能磨成针，无论做什么事都要多个角度去考虑事情，以老板的心态对待公司，不能对一个行业光说明白、知道，而是一定要学会干！人之初，性本“懒”，当你有了想法就，当你遇到困难就！成长过程是自然规律，不能拔苗助长，一山看着一山高，到了那山没柴烧！

it工作心得篇4

it运维工作直接关系到应用系统运行的正常稳定，但运维工作纷繁复杂，正规化、系统化相对比较弱，如何改变这种现状?从众多的运维工作者的成功失败中进行经验总结，并提升为运维规则，是提高运维水平，保障应用系统正常稳定运行的有效途径。

笔者通过自己的多年运维经验，总结出以下必须遵守的基本运维规则，可以大大减少缺乏经验的运维人员因为自身失误导致系统出故障的可能性。

一、系统变更、升级应先在同样的环境测试通过，执行前应有经过验证的回退预案

运维是一门经验的学科、是一门试错的学科。没有做过的东西、总是会给你出意想不到的难题，因此变更前，一定要在相同或者相似运行环境下进行测试，通过后才能在正式环境下执行变更。同时应准备好变更失败的回退预案，比如，做好系统备份、数据库备份、配置备份，固化变更前的运行现场，让变更有回头的机会。

二、对破坏性的操作要先确认符合预定方案，然后谨慎执行什么是破坏性的操作?

比如：

对mssqlserver，执行update操作，因为不需要commit，所以特别容易忽视也特别危险，还有、drop等操作更不用说。

对 oracle 而言：truncate table_name、 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本身自带的字符界面比那些复杂的图形界面要简洁方便

如果能做到坚持这九条铁规，你的应用系统就能长久稳定运行了。

it工作心得篇5

我在一家叫做 coverity 的公司工作，我住在三藩市(san francisco)。coverity 是一个奇怪的公司，三藩市是一个奇怪的城市。

coverity 制造一种叫做“静态分析”(static analysis)的软件。这种软件可以在不运行程序的情况下，经过对代码的分析，自动的找到程序里面可能出现的问题。这有点像我之前给 google 做的那个 python 分析器，只不过针对另外的语言(c，c++ 和 java 等)，分析的侧重点不同，能处理代码的规模也貌似大一些。还有就是这么多年了，久经沙场考验了。

coverity 具有世界上最先进的一些技术，所以麻雀虽小，却让很多人离不开它。恐怕很少有人知道，这小小的公司的忠实客户，包括了一系列的大拿：美国宇航局，波音，洛克希德马丁，雷神(raytheon)，bae systems，丰田，欧洲原子能中心(cern)…… 貌似几乎所有对代码质量不敢有丝毫差错，又不得不用像 c++ 这样毛病众多的语言的公司，都购买了 coverity 的产品。比如最近的火星好奇者号上的所有 200 多万行代码，都经过了 coverity 的静态分析。当然，如此精密的设备不可能光靠 coverity 查一下错就能确保万无一失，它必须依靠很多其它的技术，但 coverity 确实是这些东西的开发过程里面比较重要的部分。

我必须承认，coverity 给了我足够的启发，甚至间接的让我发现了自己之前做的 python 静态分析里面存在的一些问题。coverity 的产品在大规模的代码上面的成功，也让我意识到了自己在 python 分析器里的一些突发奇想的设计的正确性和价值。如果我现在做一个新的 python 分析器，它将比原来的精确和高效(也可以推广到其它语言比如 javascript)。我也清楚的看到，coverity 自发研制的一些“不大严谨”的做法，其实比程序语言领域里面一些看似高深的“逻辑”还要“正确”。这些微妙的“提示信息”，让我把多个领域的知识串通了起来。所以我觉得跟这公司还有点臭味相投，加入 coverity 也是不枉此行的。

然而我也发现，coverity 缺少我拥有的程序语言理论知识。绝大部分的 coverity 工程师没有系统的学习过 lambda calculus 和函数式编程。在我的 python 分析器中，其实包含了 coverity 还没有的技术。python 的静态分析本来就比 c++ 和 java 之类的难，然而我的实现却异常的简单。这些微妙的技术，貌似很多人都可以说他“会做”，但是他们却很难把它做对。这就像“cps 转换”一样，很多人都说他会做，可是真正做对的只有极少数人(我是其中之一)。这些技术源自于我对程序语言本质的理解，源自于 dan friedman, kent dybvig 和 amr sabry 等老师的教诲，也源自于我自己辛勤的实验，实验，再实验…… 在我简短而优雅的代码中，包含了许多人需要花费好几倍的代码长度才能达到的目标。所以虽然 coverity 的工程师们技术实力很强，但在代码的简单程度和对程序语言语义的理解上，真的很难达到我的程度。

这就是为什么我经常能够一眼就看出 coverity 产品里存在的问题，并且很快的修正错误。举一个简单的例子，有一天我修改了一行代码，使得产品在某些 benchmark 上的内存使用量减少了一半。我为什么可以做到这一点呢?因为在我的 python 分析器里，这个问题是从一开头就不存在的。它源自于一种幼稚的解释器写法，有点像 gof 的《design patterns》里的那种。coverity 的代码里面有好些类似的问题，都是我自己根本不可能犯的错误，我都没有机会给他们改进。我不是想贬低同事们的水平，他们都是 stanford, berkeley 等学校毕业的高手，可是我也很清楚自己的技术地位。

所以我就经常发现这样的麻烦事：我顺手改掉了一个自认为很显然的问题，或者一个我根本不会犯的错误，然后就发现有大批的测试需要被修改，我也会被要求写出“regression test”，用以防止同样的错误再次发生。某些同事对于测试的战战兢兢的态度，其实跟我当年在 google 实习的时候没有什么两样。看到这里的问题了吗?这些我“根本”不会犯的错误，几分钟时间顺手就改掉了，但是我却要花成天的工夫去修改和创建测试，防止它“再次”发生。我不得不说，在这些测试上所花费的工夫，占用了比我修改代码多好几倍，甚至几十倍的工夫!

想想这六个月以来我干了些什么，再比较一下在 google 实习的那六个月独自从头做出来的东西，我发现自己简直什么也没有干。这就是我不喜欢“测试驱动开发”(tdd)的原因。在 google 的六个月里，我无视同事对于测试的要求，从无到有的做出了如此精密的系统，一个测试都没有写照样做得好，为什么呢?因为我的代码非常的简单清晰，我随时都可以把它们完整的呈现在头脑里面，从而让“心灵之眼”可以看到可能出现的错误。也许这就是所谓的“逻辑思维”。

对测试过分依赖的人，往往不具有这样的思维能力。他们不能够看到代码最简单的本质，所以需要做很多试探，以求达到“近似解”。为了不至于偏差很多，就写很多测试，用以捕捉和防止每一次的错误。这就像一个初学画画的人，一点一点的描，用橡皮反复的擦，可总也抓不住事物的精髓。这些人对“错误”的记忆能力特别强，往往深入的追究一块代码是“如何”错的，“为什么”是错的，下次如何才能不犯同样的错误。

然而我却没法记住之前的代码是如何错的，我也不想知道为什么它是错的，我只记得“正确”的代码是什么样子。错误的方式有千万种，可是正确的却往往只有一个。把脑力浪费在记忆错误的东西，这就是为什么很多人不能写出真正优美而正确的代码。我受到的训练让我可以直接得到正确的结果，所以测试对于我来说分量没有那么重。当我的代码需要大量的测试才能确保正确的时候，那就是它该被推翻重写的时候。所以我的代码往往没有任何补丁和变通，可以说是无懈可击。这就像是一个真正会画画的人，他闭目沉思，然后一气呵成。当然，优美的代码并不是一蹴而就的，有的代码被我推翻重来几十次才最后成功，但我最后的代码不留下丝毫错误的痕迹。所以我觉得，看一个程序员的水平，不要看他留下来多少行代码，而要看他删掉了多少行。

我觉得做 coverity 的工程师真累。这种累不止在于以上的技术层面的繁琐，而且在于管理层对工程师的缺乏尊重以及不必要的压力。这让我在受到了足够的“启发”之后，开始怀疑是否还有继续为它工作的价值。对于公司管理，以及对于 it 行业总体的看法，我还是以后再讲吧。

it工作心得5篇相关文章：