在这篇文章里，鄙人将给大家分享下我个人对于IT工程师事务规划上的一些体悟感受，欢迎拍砖。

项目 + 任务驱动制

以运维（开发）人员的视角来看，所有工作上的事务可以划分为两大类：Project & Ticket.

具体来说，项目就是一些计划中的任务集，它可以是类似爬虫应用这样的研发项目，也可以是像Memcached运维这样的运维项目。一个项目意味着很多的日常事务，也是日常工作中最花时间的。

工单（可以是逻辑抽象层面的概念，比如某用户的一个需求）则是一些来自各个用户的需求，我们无法保证我们支持的项目集能够满足所有用户的需求，这个时候就需要接受他们的一些特殊需求，并且相应的评估 & 跟进。

除此之外，我实在想不到更多可以做的事情了 :)

最后，我们工作上的事情也许会是这样的：

  • 爬虫项目开发；
  • 爬虫项目运维；
  • Memcached 调优；
  • 老大要求收集所有机器的某些参数指标汇总成报表给他看一下。

那么，Project + Ticket能否再细化抽象一下呢? 我想，它当然是可以的，我们可以将项目和工单的所谓“需求”，比如某应用需要开发某些功能、运维手上一些应用的改造调优以及一些用户的特殊需求（即个性化的ticket）统一抽象成“任务”。

那么，很明了了，我们事情的规划最后可能会变成这样：

  • （爬虫项目开发）为某业务的调整，修改爬虫代码抓取逻辑；
  • （爬虫项目运维）为某些爬虫客户端机器安装指定的包并做配置；
  • （Memcached运维）为Memcached机器调整Linux内核参数和swap设置；
  • （额外ticket）收集机器参数指标，汇总报表；

所以，首先，我们知道了我们需要做些什么事情。 Ps. 印象笔记是一个不错的APP，也许我们可以用它做载体 :)

总结和回顾

既然我们已经清楚的知道了自己所要做的事情，那么当然得需要进一步，我们得做回顾和总结，比如说Memcached 运维这整个的项目集耗费了自身很多精力，那么或许应该问自己几个问题：

  • 是否做的事情都是有价值的呢?

当我们做一些总结和回顾的时候，首先得判断做这些任务的收益是否达到预期，也就是我们是否在做一些本不需要做的事情呢? 比如一些删除文件的动作，本来可以交给crontab之类的计划任务来做，自己去手工做这个事情便没有任何价值，又比如制造出一些没有人消费的数据，这也是没有价值的。

在我看来，评判一件事情是否做的有价值，首先一点，如果跟老大汇报说，我正在做这个事情，老大会不会认可? 其次，这个事情做完了，是否会产生一些积极的变化? 最后，花费在这个任务上的时间与实际的收益是否成比例?

在理清这些之后，我们完成任务的效率及获取的收益也许会更高。

  • 是否做的事情存在 > 10次的重复呢?

如果一个任务，被重复的操作超过10次以上而没有任何改进，那么你得警醒了，是否这个任务还值得继续这样的重复劳动呢?

IT 界近几年提出的xx自动化正是源于对重复劳动的深入改造。无论是半自动化，还是全自动化，自动化的需求驱动便是“它实在被重复太多次数了”，另外，自动化需要一些前提，本人总结为：标准化 & 流程化。

以爬虫自动抓取网页数据为例，如果HTML的代码结构不是规整的XML格式，如果抓取的目标源不能通过正则匹配的方式很好的抓取出实际数据，那么爬虫的自动化抓取便永远只是一个梦，这就是所谓的标准化，你首先得保证这个任务是非常标准的并且能很好被拆解的。

而流程化则是指这个重复完成的任务，本身是可以按照固定的流程或者工序去完成的，也就是说它的解题逻辑是非常固定的，倘若无法达成这一点，自动化也是很难推动的。

其实如果能够做到半自动化，相信也是有巨大价值的，比如我们可以不再关心具体的技术细节，只需要按照需求，在Web上点几个按钮即可完成，再比如我们可以通过开放Web工具的方式，直接暴露给最终的需求用户，让他们自助服务，从而实现解放双手的目的。

积极了解行业变化

IT 行业日新月异，每分每秒都在发生巨大的变化，如果你不关注到这些，那可能会重复造一些轮子，严重的，可能会被时代所抛弃。

比如说，当开源界已经诞生了Linux系统的时候，我们再造一个OS便是愚蠢之举了。又或者，当业界出现种类繁多的开发语言时，我们还固执的使用着单一语言做开发便又是显得过时了。

时时刻刻的关注自身所在的行业的变革，关注Github、InfoQ、51CTO等一些技术站点的资讯以及新兴技术，无疑会给自己的工作有很大的助力。值得一提的是，当你从事某项职业的时候，融入到这个职业的圈子也是个不错的想法，比如运维喜欢加一些QQ群，喜欢参与一些技术分享，喜欢参加QCon以及逛Linux Tone，多和业界的同僚沟通交流，可以给自己更多的灵感和机会（比如跳槽~）！

就是这些了，以上仅仅是鄙人的一些个人感受，不喜勿喷~