系统管理是一个多元化的工作，作为一名系统管理员，我们一般不编写程序，也不从事设计工作，我们的工作就是将各个厂家的产品协调好，为各种系统正常运行建立一个和谐的环境。

　　一般没有人赞赏系统管理员的工作，不信你可以向老板报告，你编写了一个新程序，看看他是否会将你的程序贬低为一个脚本，仿佛使用Java和C编写的程序就比使用Perl和Python编写的同样功能的程序更高尚。显然这样会严重刺伤系统管理员的心，导致其成为一次性使用的东西，懒得编写文档记录，因为人们一般只注重结果，不注重过程。

　　我举一个例子，监控工具如Zabbix，Zenoss和Nagios都可以为你提供一个基础设施监控框架，但它们很难满足每一个需要，因此你必须自己创建自定义的监控配置和插件，以满足工作需要，但问题是，你仅仅是编写一个插件让它运行就完事了吗，还是要经过创建，修改，编写文档记录和打包这一系列过程？抑或为未来的改进创建一个路线图？换句话说就是，你只是想应付一下还是想将其变成产品？

　　努力将Hack代码变成一个产品可能没有多大意义，但确实需要一种不同的行事方式，让我们看看这两种行事方式所涉及的步骤，看看有何不同：

　　创建一个Hack解决方案：

• 找出问题的症结
• 研究解决问题的方法，选择最佳（或最方便的）解决方案
• 实施解决方案
• 测试解决方案
• 修改或改进解决方案，直到它解决了最初的问题
• 结束

　　这里我们看到的是最常用的方法，在实际中可能需要反复Hack直到它能工作为止。

　　当你你把问题解决了后，人们都很高兴，这个时候你可以回家喝点啤酒庆祝一下。但是当你需要调整Hack方案时你该怎么办？如果过了半年，它坏掉了，你又忘了当初是怎么做的时怎么办？我不知道当一个技术人员看着一段Hack代码，但又不知道是谁写的时候是什么表情，这和一次性解决方案的本质是一样的，这是一个很不好的习惯，我们不推荐你这么做。

　　现在我们以产品的行事方式来看看同样的过程。

　　创建一个产品：

• 找出问题的症结
• 研究解决问题的方法，选择最佳（或最方便的）解决方案
• 在版本控制系统中创建一个新的目录/项目
• 创建一个README文件，记录你要解决的问题，你选择的解决方案以及为什么这么做的原因
• 实施解决方案，将你的思考过程记录到在线文档，同时更新README文件
• 测试解决方案
• 修改解决方案，检查每次测试之间的变化
• 完成后，打包成一个易于安装的格式（RPM，tar包，安装脚本等）
• 测试部署，根据需要修改
• 给库加上标签，并将安装包移到中央存储库（FTP服务器，Web服务器等）
• 结束

　　开始时可能难度比较大，但如果你把心态放正，其实也不难。即使这只是一个配置文件或只有20行的shell脚本，你制作的也是具有长期价值的东西。如果你需要修改解决方案或实现类似的东西，无论是产品的一个新版本还是一个分支，你都可以快速出色地完成任务。只要稍微多付出一点努力，你就可以将一次性的东西转变成产品，可重复使用的产品提升了其本身的价值，同时你离开后，其它雇员可以继承你的工作。

　　如果你认为我是在开玩笑，请你三思先。当你第一次解决问题时，可能会觉得这并不重要，但当你以后需要复制或调整它时，你对这个问题可能就有完全不同的看法。更多时候，在开始阶段要思考和研究的时间要多一点。即使它只是一个MySQL配置文件，如果你在my.cnf文件中增加注释，然后与README文件一起打包成一个tar包，也将带来巨大的价值。

　　如果你不这样做会发生什么呢？很多时候，你需要回到起点，重头开始实现解决方案，如果你对最初的解决方案比较熟悉，那重做起来还是比较简单的，但这不是在重新发明车轮吗？

　　每一个产品都需要一个过程，但一个好的产品也需要一个产品经理来进行管理。如果你与其它管理人员协同工作，虽然每个人都可以独自分担一些责任，但大家不能太过分散，这很重要。以我们的监控业务为例，如果产品经理能从更广的角度去思考，对整个监控业务是非常有益的。产品经理需要考虑如何将多个产品和解决方案集合到一起？如何随时间的推移进行改进？他并不需要做所有的工作，但他需要看到大局，让每个人都朝着正确的方向努力。

　　如果一个产品经理的想法看上去有点不切实际，这个时候你应问问你自己“谁真正知道未来会发生什么呢？”。在很多公司中，如果你只是问“是谁在负责监控？”，你可能会得到相互冲突的答案或他们装着不知道。如果你的组织也是这样的话，你应该坐下来，在纸上列出你部门的职责，并与每个人的名字关联起来。就象我说的，产品经理并不需要做所有工作，但他是团队的核心，虽然在这个岗位上的人可能随时间而改变，但总是有一个相同的称呼。如果你配置这样一个角色，就应该相信他，聆听他的意见，给他足够的权力，加速走向成功。

　　在你的README文件中，要包括后面这些信息：最初设计和实施该解决方案的人是谁？现在的维护者是谁？产品经理是谁？这些内容通常都容易被忽略或遗漏，因为我们认为它是很明了的，或是不会改变的。这种想法在交接时必然给我们自身带来麻烦，因为可能几年后，人都换了几拨了。

　　一切都应该产品化，至少我希望我已经提供了一些令人信服的理由，通过这种行事方式可以使你的组织更专业，更高效。开始尝试一下吧，总是听人家说多没意思，同时应无私地将你的心得与大家分享。