1.  7月某个周末去广州玩，下午5点准备回去的时候，电话报障短信下发内容没有剩余积分，用户反映很大，需要尽快处理下，赶紧朝回 赶，7点赶到局点，跟踪流程分析日志发现调用命令字返回失败，取不到积分的内容，导致下发的短信内容为空，就在想这个问题为什么现在出现呢？因为前几天刚升级了一堆的流程，应该和那个有关，找到需求仔细核对文件最后发现把接口动态库文件的版本取错了， 需求中多个动态库文件，升级说明中也没有特别提示，导致我用的不是最新的版本，用最新的版本替换后问题解决。看来以后升级时还是要仔细核对版本文件，避免类似问题再次出现。不过后来的需求说明都有所改进，包含多个相同文件的，会注明那个是最终版本。

2.  7月佛山来了两个新同事，主要是来搞知识库升级、IVRMAP、Telsales的开局的，自从他们来到后，佛山局点就开始热闹了。  

3.  8月的第一个周末，安排佛山区域值班，不过这个时候还不是全省性的值班。  

4.  8月中旬的3天在广州学习多媒体坐席的部署调试，随后赶回佛山开始了佛山的多媒体坐席部署调测，基本上搞了1个多月佛山的多媒体全面 使用，不过也有好多问题没解决，主要是当时研发不重视这个项目，也没有多余的人来支持，所以事情搞得很被动。直到最后要验收的 时候才派了2个人来现场处理遗留的问题。当时一个严重的问题是测试完后关闭WEB呼叫窗口后,经常出现无法弹出满意度调查窗口或者弹出窗口为空白，由于满意度关系着座席的绩效，反应很强烈，但用户在外网使用并没有反应，就怀疑是代理的问题，因为内网通过代理访问客户端公网IP，进一步测试发现登陆10个客户端后系统响应变慢，任务管理器IE进程句柄持续增加，超过2000后响应变慢。原因是请求被proxy服务器丢弃，导致 AJAX客户端大量超时。后来找了十个人在网吧测试未见异常，还真是代理的问题。

5.  当时9月的重点项目是知识库系统的升级割接，从PC机升级到小型机上面，升级到没什么事情，但升级完后每天下午6点后知识库就运行的非常慢，根本无法查询，但重启服务后又正常了，分析了日志也没看出什么就没太在意也没人管，就这样慢了重启持续了1周多，客户终于发飙了， 再不把这个问题从根本解决，马上上报到省公司，这下大家重视了，马上组织研发专人跟踪，把配置文件、各种日志文件发给研发，最后发现是配置文件配置了两个小时重建一次索引（知识库的核心技术就是搜索功能，用的是索引文件），18点正好是话务高峰期，开始建索引小型机资源耗尽，而重启服务后终止了建索引，资源就恢复了正常。而且知识库的内存分配也不合理，调整后再也没有出现过这个问题。

6.  9月又同时在进行佛山BOSS割接，割接地点在顺德，导师当时主要跟BOSS的问题，我在佛山主要关注知识库的事情，那段时间的故障真是 多如牛毛，知识库最杯具的一次是某天下午5点后升级了几个页面文件，用的是FTP方式（ftp://IP），升上去后知识库就打不开了，重启了服务这下杯具了 服务启不来了，正好是使用的高峰期，最后决定重启机器，谁知shutdown –Fr 后，等了半天没反应，PING IP地址发现不通了，这下玩大了， 一面赶紧去南海桂城机房处理，一面先切换到应急系统上面，折腾了几个小时才搞定。后来有人分析说是FTP上传方式破坏了文件的格式，导致服务启不了，我感觉这个说法很牵强，几个HTML文件会对小型机造成什么影响啊，又不是配置文件，何况IUAS服务器也是FTP方式上传的 ，怎么没有出现问题啊。不过有人这样说，咱也跟着这样说吧，到底是怎么回事鬼知道（知识库的小型机是从数据库退役过来的，已经用了好几年了）。当时现场定制开发也派人来协助处理知识库的问题，基本搞了1个月。

7.  9月底启动省iod短信接口的割接，主要是把满意度短信割到省IOD，从部署短信发送服务器、安装IVR、升级满意度调查流程等要在2天之内完成， 国庆开始启用。短信的大概过程是：座席通话结束-->转满意度流程-->自启动流程扫描数据-->写数据库-->媒体发送服务器-->短信前置机-->省IOD-->用户手机（短信上行与此相反）。

8.  9月29日晚导师和另一个同事当晚去了武汉欢度国庆去了（听说导师是武汉大学当年的理科状元），我30日请了两周假也准备回家了，佛山一下就成了真空了，当时就害怕出事，走之前给 广州同事说让关注下佛山的事，出现故障连过去看下。谁知害怕出事偏就出事了，坐火车还没有出广东就电话报障座席入线错误，赶紧联系广州同事登陆过去看下是什么原因，后来电话也没信号了，就不清楚了。不过入线错误也是个小问题，通常是配置被改动了，还可能是平台的问题，不过这就复杂了。

9.  10月15日休假结束，回来上班，打开邮箱几百封未读邮件，花了一上午才把邮件搞完，什么事情也没干成，最反感的就是发一堆垃圾邮件，小范围的 事情点对点讨论即可，最后把结果发出来就可以了，群发邮件就是浪费大家的时间和精力。

10.  以前需求上线一直是华为自己主导，客户并不参与，只需要把结果告诉客户，但从现在起需求上线必须由ITC、业务室、华为三方共同参与，ITC主导协调资源、业务室测试、华为负责上线部署和问题处理，上线结束后三方签字确认，但这个时候还没有要求写升级方案。10月需求上线前三方先开了个会，确定了上线的时间点，遗留问题的处理时间等。到了上线的晚上开始升级前，ITC和业务室派了两个实习生来，两人对需求一点都不熟悉，需求文档也没有学习，基本上什么也不会，当天晚上问东问西指手画脚的，我实在是忍无可忍了（有人说过忍无可忍则无需再忍），就把两人批评了一顿， 结果第二天两人向项目经理投诉我服务态度不好，随后项目经理打电话问我情况，我就把当晚的情况客观的、实事求是地说了一遍，最后项目经理说以后还是要注意下态度，一般不要与客户起冲突。这个鸟事件到此就结束了，但对我确产生了重大的影响，具体以后再说。

11.  10月某天下午快下班时短信满意度不能下发，问题有点严重，短信满意度的规则比较复杂光是存储过程就用了十多个，马上联系现场定制协助处理，并告诉他们最好不要私自修改，由现场统一修改，过了一会前台直接报障说座席大面积出现白屏定死，赶紧检查发现T_PUB_comminfo表被锁，此表有上千万的数据每秒调用上百次，此表死锁座席不死才怪呢？打电话问定制才知道他们test线网存储过程导致的，最后只能把进程KILL掉，座席才恢复正常，满意度也不敢让他们搞了，还是自己搞安全。后来根据日志发现某个存储过程返回失败，分析算法原来是有人修改了下发规则导致的，应该又是业务室搞的，这些人修改前老是不通知，到出了事才想起找你救火了。第二天ITC让我们写一份故障报告，座席定死那可是严重的故障，最后  写了一份说是业务室修改了数据导致不能下发，我们在处理的时候test导致锁表等等，ITC也拿业务室没办法。没敢说是定制搞的锁表，因为一再强调非现场人员严禁操作线网设备，第二天在内部把这个事情通报了一下，所有人员务必把信息安全放在第一位。

12.  时间进入11月，某个周日下午报障说WEB配置台无法登陆、短信下发延迟的故障，当时正在外面玩，一个电话看来有玩不成了，赶紧赶回局点，先检查短信下发延迟的故障，发现媒体发送服务器有大量发送进程，一般最多20个进程，再多的就只能等待，检查相关表发现有5000多条短信堆积，一般缓冲5000以内是正常的，这种情况只能先把扫描进程先关掉，等把缓冲中的短信发完后再打开，主要是系统的处理能力有限每秒100条，一天下发200多万短信在高峰期压力还是很大的（所以后来才部署了MSP平台，主要来处理短信、彩信、WAP、Email等）。再看WEB配置台无法登陆，检查机器发现机器资源耗用的差不多了，直接重启了服务，释放资源后可以正常登陆。

13.  11月某天上午，正在上班接到ITC电话说前台的座席全部退出有重新签入，你们查下是什么原因，检查平台日志发现是CCS主备倒换，询问了业务室得知是他们加载配置数据，看来应该是这个原因了，不过为了严谨还是把日志和CCS版本号发给研发，最后研发给出的分析报告也是那个原因。后来根据研发 的分析给ITC提供了一份故障报告（平台故障都属于严重故障，必须给故障报告）。谁知过了几天一天晚上正在吃饭，又接到电话报障座席又发生了全部签出再签入的情况，第二次分析好长时间也没有得出详细原因，不过两次切换对系统没有任何影响，ITC也没有深究。

14.  11月某周末晚上接到电话报障说1008611无法下发短信，需要紧急处理，赶到局点，跟踪流程测试分析日志发现是命令字返回错误，取不到用户的短信内容，开始因为是BOSS的问题，不过再仔细看发现流程的版本日期有问题，所有流程都是我加载的，我知道它的日期，这个流程文件明显是被人修改的，能修改 这个的除了ITC估计不会有别人了，公司规定严禁任何人随便修改现场需求版本，所有的版本修改后都要归档，不过ITC倒是经常按他们的要求私自修改 版本，也不是一两次了，不管他先换回统一版本，更换版本后测试流程正常。后给ITC发邮件说有人私自修改版本导致了故障，ITC自知理亏也没有说什么，至于版本的问题告诉项目经理由他去交涉，我们也省的得罪人。

15.  12月的一个需求需要在排队机上加了075710086XX的业务字冠，属于高危操作，等到晚上1点才开始，加完后测试能打通就收拾离开了，肚子饿了先去粥家庄吃个粥，粥还没上来电话就响了，晚上打电话绝对不是什么好事，果然报障说佛山的电话打不了了，赶紧打电话测试听见嘟嘟嘟几声就断了，赶紧返回去先跟踪主流程发现电话根本没有进来，应该在进入平台前就出问题了，马上跟踪排队机被叫号码，分析排队机跟踪信令，发现信令走到新加的 075710086XX上面了，而这个是没有加语音是听不到声音的，应该是这个原因了，把075710086XX删除，再次拨打恢复正常。有测试了其它3个地市的 正常。随后向各区域发邮件通知了故障，这个需求停止上线。处理完这个已经凌晨3、4点了，肚子饿的咕咕叫，再去吃粥，粥钱已经付过了。第二天下午上班后给ITC说明了故障原因，说这个需求是业务室要求升级的，ITC拿业务室也没办法，说这种高危操作一定要谨慎，不要尽听他们的，这个事也就这么结束了，那个需求后来也没上。

16.  12月广州、东莞、佛山三个局点的人员轮调，项目经理找我谈话说你们两个都被客户投诉过，不适合在佛山待下去了，准备调我去汕头，问我的想法，我说随便了哪都一样，随后就来了两个新同事，需要工作交接，但客户得知我们俩都要被调走，就找项目经理说把两个人全调走，来的新人对佛山的情况不熟悉，不利于佛山系统的稳定，必须得流下一个人，在客户的要求下后来我又被留下来了，导师调去了东莞，来的一个新同事去了江门，江门的一个去了汕头，这样六大中心各留一个走一个，保持局点工作的稳定性。