共计 2095 个字符，预计需要花费 6 分钟才能阅读完成。
| 导读 | 远程分布式系统管理团队能够凭借着跨越全球各时区这一巨大优势保证随时可对突发状况进行解决，同时也带来了更为丰富的人才储备池供企业使用。而在具体工具方面，我们一同来看 OpenStack 全球基础设施团队选择的五款开源协作方案。 |
我们使用的是由 freenode 公司提供的 Internet Relay Chat(简称 IRC)，能够与之对接的开源客户端可谓多种多样。在它的帮助下，我们能够随时探讨问题与挑战、构建解决方案、通知进度变化、发布项目状态变更与警告，并设置了机器人负责待审查的基础设施变更提交内容。我们使用的 IRC 频道完全公开，同时设置了专门的频道记录服务器供各位使用者随时查看。
以下为某天早上我们的一小段频道聊天记录：
<clarkb>hrm no world dump on that failure?
<openstackgerrit> Anita Kuno proposed openstack-infra/storyboard: Add example commands for the Timeline api https://review.openstack.org/337854
<openstackgerrit> Victor Ryzhenkin proposed openstack-infra/project-config: Add openstack/fuel-plugin-murano-tests project https://review.openstack.org/332151
<clarkb> its definitely an io error of some sort
<clarkb> possibly run out of disk space?
<therve> The df output looks normal...
<greghaynes> or, is it writing out to tmpfs?
刚刚上手时大家可能会有些不适，但熟悉之后这里的对话与日志内容将成为我们的宝贵资源。
另外，在带宽充足的情况下，我们也会选择进行语音通话——我们选择了 Asterisk 系统来支持 Voice over IP(简称 VoIP) 呼叫。
在企业或者组织内部运行专有 IRCd 的作法非常常见，而且此类开源选项也很有，大家可以根据需要进行随意选择。如果您的团队更希望使用现代界面与功能，那么建议大家选择 Mattermost。
Etherpads 属于托管型协作文本编辑器，允许部门团队以实时方式同时编辑同一文件。我们的团队利用它实现了多种用途：立足整体项目公告进行协作，分享个人思路、观点与议题，编写维护与升级规划，外加通过维护窗口执行任务等等。
我们通常会将 Etherpad 与 IRC 协作配合使用，其中 Ehterpad 负责充当笔记同步平台，我们在这里进行讨论并记录下一切重要信息。另外，我们在自己的基础设施当中使用的是开源 Etherpad Lite。
Pastebin 允许大家将大量文本粘贴进来，它会返回一条 URL 以供我们共享给其他团队成员。在我们的团队中，这意味着成员可以轻松共享日志片段而无需访问服务器。事实上，我们往往将 Pastebin 与 IRC 频道结合起来，或者通过 Etherpad 提供只读文本内容。
目前有多个开源项目能够实现 Pastebin 共享效果。我们目前使用的是 LodgeIt。如果大家打算运行公开 Pastebin，则记得使用 robots.txt 文件阻止其内容被搜索引擎检索到。
作为一套被官方称为终端复用器的方案，GNU Screen 允许大家在终端会话当中运行命令，同时在登出后确保应用继续运行。这种能力在我们管理长期运行且需要手动触发的命令时非常有效。大多数团队成员都利用它确保我们的 IRC 客户端能够 24/ 7 全天候运行。
更有趣的是，我们还利用 GNU Screen 会话帮助团队成员学习系统管理技能。系统上的部分用户还能够附加一个屏幕会话以实现终端会话协作。在这里，我们可以向团队新成员提供访问密码值，或者共享复杂的维护任务执行规程。
当然，大家也可以根据需要选择其它选项，毕竟 GNU Screen 在现代功能方面显得比较单薄。备选方案包括 tmux 与 Byobu。
Git 项目当初是由 Linux Torvalds 为管理 Linux 内核开发所建立。Git 目前已经成为开源项目领域最具人气的版本控制系统，每个系统管理团队都应当利用此类版本控制方案对基础设施的变更进行管理。对于跨时区团队而言，我们往往很难找到对大家而言都比较合适的八个小时。这时，Git 能够帮助成员们查看系统中的各项变更，从而了解自己睡觉时地球另一头的伙伴干了些什么。
另外，我们还能够更轻松地实现状态回滚，或者至少查看破坏性变更部署之前的正常状态。再有，我们也可以借此描述每项变更的内容与理由。
提示：作为管理员，大家务必要在提交变更时注明进行变更的理由——毕竟在几周甚至几个月之后，可能连变更提交者都不记得自己当初为什么要这么干了。
