此文献给在工作遇到困难,并想放弃的人。
一份工作，除了带来稳定的收入外，还需要赋予其他的情感，才会热爱、长久，大部分时候，我的工作是这样划分的：
第一类，占总时间的1/2，用于新技术研究和运用；
第二类：占总时间的1/4，用于处理求助/救急；
第三类：剩余的1/4，用于熟练的任务。
在第一类和第二类的工作中可以得到较多的成就感，当然伴随的焦虑感、无助感也不算少。
最深感悟：撑住==成长
新技术使用，已有确定的上线时间。
docker刚完成基础学习，就立马投入现网使用。
ELK前一天刚模拟出来，第二天就部署现网。
Kafka是个替代方案，因下周二要做验收，开发人员调配不开，来不及开发，于是将日志写入Kafka，写个小程序处理Kafka的数据再输出。
研发一天开发小应用，而我这边一天时间弄Kafka，工作安排上就是并行的，根本就没有万一遇到问题无法解决这一设定。
以上，都已按时在线上出现，在现网部署的这条路上，大有运神杀神、运魔杀魔的气势。
**
高压 是技术进步的最佳的手段，只要你能扛住，没有退缩的想法。
**
现网故障，限时完成。
一般客户对故障都有个处理时间标准的，30分钟内算事件，超出30分钟算事故，要通报，之后一堆麻烦事，谁都不想走这个流程。
然而现网会出什么故障是无法预知的，谁也不能百分百保证只要出故障就能在30分钟内解决。
一般故障流程：出故障->发现故障->运维部门处理->解决->告知客户原因。
到我这里流程：出故障->发现故障->运维部门处理->无法解决->转到我这里->解决->告知运维部门->告知客户原因。
有利：常用的手段运维部门都试过一次。
不利：要另寻出路。
任务要求：尽快解决。
上周故障一：虽解决了但留了个后遗症，因成员提供的信息有误（而我没有去验证），下达了错误的指令，导致后期要补数据。
上周故障二：故障出现已过1小时，但未解决，转手到我手里。常规解决方式运维部门都已试过，拿到服务器信息后，立马重现报错信息，根据报错在网上搜索，找到一个类似的，分析后觉得即使不能解决问题也不会出大错，于是就执行了，反馈给我的是报错信息，看似这方案无效，仔细分析后，立马拆分，手补，反馈正常，复查后确实已OK，是非常顺利的一次故障处理。
从接手到解决 用时23分钟，有运气成分在，感谢搜索引擎，感谢前辈们，贡献方案。
给自己整理下个流程，以便减少误判。
1）向前人询问服务器信息
2）向前人询问报错信息和已做的操作
3）确认前两项信息的准确率
通常会重复下常规解决方式
不是不信任，而是每个人理解、判断方式都是不同，遇到过好几次 常规方式就能解决的问题，因操作不当而没有产生相应的效果。
4）正式开动
借助自身的资源库，搜索引擎
快速判断别人提供的方案是否和自己类似，是否可用，尝试后可能的后果。
5）选风险最小的方式 尝试
对于故障处理，我的技能储备并不会比他们多多少，他们不会的，我也同样不会，只是他们有退路（转手给他人），而我没有。
看似我在吃亏，其实我得到的最多，每次限时任务，都是增长判断能力、反应能力、技术能力的最佳机会，跨过去就是成长。
帮助他人
现团队有9人，他们遇到无法解决的问题，我通常是两种处理方式，
一：告诉他去找某某某 （前提：我知道某某某一定是可以解决的）
二：自己动手
这里更多的是一份责任感，对成员的维护。
这也是个互相学习的过程，有时我也郁闷，为什么他们总会遇到非常妖孽的问题，但我深信 任何妖孽的背后都有一个逻辑，找到它，就能解决问题。
有时，我们一起搜索，翻看文档，交流解决方案，这个过程是非常愉快的，在梳理过程中，我可以从对方身上得到很多灵感。
有时，我们分开行动，当我独立解决问题却没有合理的理由去解释时，我感知自己技术／知识的欠缺。
成长：不回避自己的不会，和他们一起进步。
我工作11年，几乎每天都遇到自己不会的，但经验就是这么积累的，别人告诉你的，都是别人判断逻辑后的结论，你不会的依旧不会，倘若你能学会判断出结果的这个过程，你就会变得与众不同。
加油吧，趁年少！
