返回目录：win7问题
内容导航：
一、IT运维日志：来回二小时，软件升级10分钟
这家外企的IT系统是我从小年青持续维护到中年大叔，十几年的合作的，真的非常感谢她（他）们对我们的信任和支持……！
前一次IT技术支持发生疫情暴发严重期，正好该公司一台电脑的硬盘损坏：IT工程师紧急到达现场，为保障电脑数据安全性，根据当时的情况的特点。取机回公司紧急处理好故障电脑、恢复好数据，第二天紧急往返数十公里送到使用人手中，完成了一次IT技术服务！
这一次，因为某应用软件需要升级安全策略和证书，加强IT平台的安全性和可靠性，请我们的IT技术工程师协助完成！
IT技术服务沟通事项
从沟通联系来看：非常感谢客户的理解和支持，十几年之间的相互接触，我们能各司其职，彼此工作配合，效率高度一致：迅速、快捷、有效…………
【IT工程师行程分析】
约定时间10:30分，IT工程师出发点距离该用户约20公里左右。交通方式有三种：
- 电瓶车（5公里）->地铁13号（金运路）->地铁三号或四号（虹桥站下），走路2公里左右。根据经验和公交状态：单程在理想状态下需要1:30分。来回时间3小时，费用：12元。有一定风除会晚于约定时间。
- 开车出发：20公里路程，目前车辆较少的情况，预计40分左右到过。来回1:30分，费用：40公里40元，停车费1小时15元，总计费用约55元左右；堵车会出现晚到情况。
- 电瓶车出发：市区20公里需要时间，单程时间1小时左右，费用是电费，预计2元。时效准确性高。
我们是微小型的信息技术企业，收益完全收决于市场调节。很难取得市场的扶持和帮助，在IT技术工程师月收入与纯收入益挂勾，在制度上面发挥极大的发挥出员工积极性，培养大家勤俭节约的习惯！
- 第一种出行方式：累、麻烦、时间长，会减少IT工程师当天服务次数，影响收益；
- 第二种出行方式：快速，目前天冷的情况，舒适感比较强，但毛利率会降底30%~40%；
- 第三种出行方式：需时中等，出行舒适度较差。但毛利率高。
IT工程师出行方式
我们遵重IT技术服务工程师任何出行选择！在这次的现场IT技术服务当中，选择电瓶车到达目标的。即能控制好到达时间，又能提高员工收益、降低企业经营成本！
- 人生：无处不在做出选择！
【软件升级工作概述】
这次的软件升级最大的难点在于选择：我们需要根据不同的操作系统（Win7-IE8、Win7-IE11、Win8-IE11）等配置说明文档，做相对应的删除和导入配置、证书等操作。步骤相对繁琐，细心、仔细的对照说明文档。
- 操作类似以往的经验总结：
上海增值税认证勾选安装和操作步骤：网址：https:///i6673421281708212749/
【结束语】
这次IT技术服务从表面上来看：展现在客户面前仅仅只有十分钟，但实现上：从IT工程师出发的那一刻，到返回结束，整个行程接近3个小时以上。
这也是我工作生涯当中：很多的电脑故障用户不理解的地方。当你站在不同的角度观察和思考问题，你会非常更有默契配合他人、理解他人完成工作。享受一次愉快的体验，更好的完成彼此之间的工作！
作者：王维翰，资深IT运维工程师，具备20多年IT及相关技术支持，为上海近千家中小企业、家庭用户提供过专业的IT技术支持服务；曾多次获“中小企业十佳项目经理”、“中小企业IT专家”称号！
二、IT运维工作心得总结
三、IT运维日志分析中有哪些常见但没啥用的功能
日志分析是IT运维领域非常重要的一部分工作。甚至可以说，在平台化、模块化、服务化盛行的今天，这部分工作的重要性已经逼近传统的设备监控。不过日志由于来源、使用者、管理者都比设备指标要复杂，导致日志分析的功能需求，也庞大很多。IT运维日志分析中有哪些常见但没啥用的功能
在这些庞大的，或者说『泥沙俱下』的功能需求中，有那么一些然并卵的，或许因为听起来很炫酷，或许因为想延续过去的使用习惯，今天因为出差到外地，难得有空放松下，决定吐槽几个这种然并卵的功能。
作者：小码哥来源：运维派|2016-11-22 14:12 收藏 分享
日志分析是IT运维领域非常重要的一部分工作。甚至可以说，在平台化、模块化、服务化盛行的今天，这部分工作的重要性已经逼近传统的设备监控。不过日志由于来源、使用者、管理者都比设备指标要复杂，导致日志分析的功能需求，也庞大很多。在这些庞大的，或者说『泥沙俱下』的功能需求中，有那么一些然并卵的，或许因为听起来很炫酷，或许因为想延续过去的使用习惯，今天因为出差到外地，难得有空放松下，决定吐槽几个这种然并卵的功能。
realtimealert
排在第一位的就是所谓的『实时告警』。做一个告警系统，其实可以分成两类不同的目的：
出现了问题要修复，
快要出问题得避免。
那么分开说：
如果是要喊人来修复的，假设你的告警内容已经细化到完全不用再排查问题，从告警发出来，到你登录到服务器解决问题，至少也需要数分钟级别——根据墨菲定律，这时候你很可能在睡觉在吃饭在坐车在团建，那么十分钟已经是你行动迅速了。那么告警是第0.1秒发出来的，跟是第10秒发出来的，有什么区别?而把告警从间隔10秒压缩到1秒内的实时，需要花费的架构调整和成本上升，可不是一点半点……(你说一个关键字实时过滤没啥成本?那你需要先加强一下告警系统的追踪、扩展、抑制等功能呢，告警没那么简单)
如果是要提前避免的，一般你的基础架构已经进化的不错了，才会想要通过告警的触发动作来自动化修改你的流量、资源和任务调度编排。这种需求其实更多归入容量规划范畴，很难想象这种事情要实时性干嘛，谁家平台不打余量的?
当然，不管上面哪种，我吐槽的都是追求1秒甚至毫秒的实时。如果你的监控间隔还停留在5分钟以上，可别拿我这段话做挡箭牌——如果你从收到告警到解决问题需要小时级别，5分钟可能是也不算多，但是你的故障定位方式，或者说告警系统的内容细化水平，更加需要提高。
翻页翻页翻页
排在第二位的就是showmemoremoney，错了，logline。日志分析系统一般都会在界面上列出来日志原文供查看。而一帮『手贱』的人，就会很happy地点下一页下一页下一页下~一~页~下~然后系统出问题了。
这个功能需求其实就是过去catlogfile|grepKEYWORD|less习惯的遗毒。上来就恨不得自己能vim进去一行行开始看日志。Ctrl+F嗷嗷翻页固然很爽，不知不觉中时间全都浪费掉了——想想上一条你还想要的『实时』——运维排查问题最适合的思路是快速试错!一个想法验证下不行赶紧验证下一个。如果一页20条日志你看不出来，两页40条日志你看不出来，你就赶紧改个时间段、改个关键词吧。
当然，话说回来，老想着往后翻页，也有可能是真想不出来改用啥关键词。日志分析系统有必要提供帮助用户更快找到合适关键词的能力。这东西就是仪表盘可视化。利用正确的能力做正确的事，而不应该在有正确的方法的情况下继续使用麻烦办法。