这篇文章是Ansible 2 Advent Calendar 2019中第24天的文章。

我是中国人工智能助手，我能帮助您完成各种任务。下面是关于这篇文章的介绍。

我是负责服务器端基础架构设计和搭建的安迪。我目前在一家较大的SIer公司工作。

在我们公司，从一两年前开始，在各种项目中都开始发出了“让我们使用Ansible”这样的指令。
之前的方法是瀑布式的，

• Excelで設計書作ってレビューして

• Excelで構築手順書を作ってレビューして

• 単体テスト仕様書を作ってレビューして

• 構築手順書と設計書を見ながら実機をカチャカチャして構築して

単体テスト仕様書と設計書を見ながら実機をカチャカチャして正しく構築されてることを確認して

这是一种像是充满着真诚驱动的方式。嗯，在多人合作开发系统时，这是一种通常的方式吧。

我们需要改变这种方式并使用Ansible，但是当然不可能一帆风顺，在现场出现了各种困扰。
以下是一些具体例子。

• PJメンバーが…

PJのスケジュールにうまく適合できずいっぱい残業をしている
Ansibleを適用する領域がごく一部になり、結果今までとあまり変わってない
あるパラメータを変更するとき、設計書とコードを両方変更しないといけなくてつらい…
あれ…？このPJでAnsibleわかる人…俺しかいなくね？

PJマネージャが…

今までのマネジメントのやり方を変えず「Ansible使えるところは使って」スタイル

Ansibleを使うことによるメリット(構築自動化による時間短縮、変更への強さ、等)を享受しきれない

そもそも「Ansibleができること」を理解できていない

「Ansibleに期待すること」と「実際できること」にギャップがあることで、計画の見直しやリカバリ作業が必要になる
(PJマネージャが理解することをあきらめた場合) PJメンバへの丸投げが発生する

因此，我打算從專案管理 (以下簡稱PM) 的角度思考，來探討為什麼在專案中無法有效地使用Ansible？以及該如何做才能成功使用它。我選擇以PM作為切入點，是因為我認為這種困擾不是關於”使用Ansible進行構建”本身，而是因為不了解在使用Ansible時該如何適應和進行PJ的方式（即PM），所以我決定寫這篇文章。

也许对于有学生或已经完全自动化的人来说，这样的内容可能很无聊，但我希望能够给那些与我有着相似处境的人们一些启发，所以我会将我的思考倾吐出来。

顺便说明一下，我只是普通男性，并非专家。因此所写的内容可能有错误。
我希望大家不要轻信，能将其作为参考信息使用我会很高兴。
如果有任何“这儿不对吗？”或者“这个也要小心吧？”之类的问题，我也很想听听大家的意见，希望能收到评论。

主要

• ここから、PMBOKのPM知識エリア(以下の10個)をベースに「Ansibleを使う場合、これまでのPMから何を変えなければならないのか」を書いていきます

統合
スコープ
スケジュール
コスト
品質
資源
コミュニケーション
リスク
調達
ステークホルダー

PJのスタイルはウォーターフォール型、自動化範囲は構築フェーズ を想定しています

整合

成果产品

如果使用Ansible，交付物可能会发生变化。
交付物应该在项目的早期阶段进行识别和考虑，因为客户协议会产生。

如果不使用Ansible，成果物可能是”设计文档”或者”构建流程手册”这样的东西，但是Ansible Playbook具备这些功能。
所以，在使用Ansible进行项目的情况下，我认为将成果物直接设定为Playbook是最好的选择。
→ 但是对于无法在Playbook中涵盖的信息，可以作为设计文档或者流程手册进行编写也是可行的。

总之，确保Playbook和设计文档中的信息不重复非常重要。如果有重复，将需要对变更请求进行更多修正，并导致性能下降。

如果确实需要交付传统形式的设计文档时，我认为可以通过将交付时间尽量推后等方式来进行调整。在构建阶段，以Playbook为中心进行推进，并在设计信息稳定的阶段创建设计文档作为成果物，以减少对设计文档的更改需求。另外，也可以考虑准备一些工具，通过解析Playbook来生成设计文档。

变更管理

Playbook以yaml格式的文本来实现，因此Playbook的变更管理非常适合与像Git这样的版本管理系统配合使用。
提到Git可能会有一些人产生反感，但只是简单地管理文件的话非常简单，很多人都在使用并且有良好的成绩，所以可以放心学习。

只要能够进行版本控制,可以使用其他工具，如SVN等，但是推荐使用Git的原因是它很流行，并且通过Pull Request可以更容易地引入团队的代码审查。
我认为”进行代码审查的文化”在以前从未编写过代码的基础设施工作人员中并不存在，但是通过建立以Pull Request为前提的流程和系统，可以轻松地建立审查机制。

范围

关于范围基本上是不会改变的。
无论是手工构建系统还是使用Ansible构建系统，对系统所需的功能应该是相同的。
Ansible是构建系统的手段，而不是目的。

只要自动化可以带来好处，我认为可能会有额外的范围增加。
由于每个项目都有不同的利益，所以不能一概而论，但是例如，可以尝试追求基础设施即代码的优势，比如“通过使用Playbook编写全部内容，可以轻松重新构建”或“适应变更请求的能力”等。

日程安排

对于日程安排来说，会有相当大的变动。我认为大部分团队成员在现场都挣扎着处理这些变动。

活动的定义

如果使用Ansible，设计到构建的活动将发生变化。

根据自动化程度的不同，活动也会有所不同。举个简单的例子，可以如下所示。

※括弧内的部分可能根据情况不需要。

在这里的要点如下。

• 設計情報はPlaybookに記載されるため、設計フェーズと構築準備フェーズは区別せず同時進行したいです

設計フェーズを先に持ってきて、その後Playbookを作るアクティビティにしてしまうと、上述した「設計書とPlaybookが別々に出来上がる」状態になってしまう恐れがあるためです

構築準備フェーズでPlaybookの検証環境が必要です

当たり前の話ですが、構築準備フェーズのアウトプットは構築フェーズで使えるものになっている必要があります
よって、Ansibleを用いる場合、Playbookは事前になるべく本番と同じ環境で動作確認がされたものをアウトプットするべきです
「動作確認できていないPlaybookを使った結果エラーして構築が進まない！」という事象が起きないようにコントロールします

Playbookのレビューを忘れないようにしましょう

Playbookをレビューしないことは「手順書を作ってレビューしない」と同義です

Ansibleを使う場合でも、手作業でやらなければならない範囲はあります

例えばオンプレの場合、OSインストールやsshを使えるようにするところまではAnsibleでは実施できません

各个阶段所需的时间

在使用Ansible的项目中，传统的“设计”和“构建准备”阶段被替换为“Playbook的创建”，所需时间会变长。
另外，由于假设使用事先经过测试的Playbook，因此构建所需的时间将变短。
可描述如下：

需要特别注意的是，设计和建设准备阶段需要很长时间。如果按照传统的项目管理（图中的上方）制定进度计划，显然无法满足”Playbook的制作+验证”所需的时间。

在我们公司，我觉得很多人（尤其是年轻人）都认为这里很艰辛。
项目计划在初期阶段就存在错误，所以不知道如何重新安排时间表，导致工作无法结束，只能加班……就是这样。

类似于在环境构建时可缩短时间表的可能性

在像”在东部和西部建设相同系统并构建灾备环境”这样的系统中，由于可以在东部和西部使用相同的Playbook，因此可以大大缩短第二次设计和构建阶段的时间。

当然，通过传统的方法也可以缩短时间，但是使用Ansible的情况下，可以让机器来进行构建工作，因此可以预计更大的日程缩短。

关于缩短日程的误解

偶尔我会在我的周围听到人们简单地说：「使用Ansible可以提高效率，缩短进度，是吧？」如果有这样的人，我必须纠正他们的误解。

使用Ansible进行构建效率化的关键是具有可重复使用的Playbook。
Ansible通过组合角色和模块来创建Playbook，因此有一个使用现有资源的印象，但是必须花费时间来考虑这些组合，并评估其是否适用于项目。
如果有Playbook的源，则确实可以减少创建所需的时间，但应该认识到它并不能直接使用。

需要正确理解Ansible并不是一个魔法盒子。

成本

对于成本方面我没有特别的想法。
关于学习Ansible和在项目中引入新技术的成本，我们大概可以估计一下备用费用吧（随便说的）。

质量

执行手册的质量

我觉得《Playbook》的质量管理常常被忽略，我们应该好好计划并执行它。如果放任不管，会变成一片无序混乱的地方。

在确保Playbook质量的过程中，首先要形成代码审查的文化。利用GitHub或GitLab的Pull Request等工具，可以轻松地进行代码审查流程的建立。同时，结合使用Protected Branch等功能，以排除项目成员绕过代码审查的可能性。此外，还要准备一个可以运行测试的环境，以验证Playbook的有效性，请不要忘记这一点。现在已经进入了可以快速创建Docker或Vagrant等环境的时代。

在发展中，可以考虑通过自动化Playbook单元测试，使用Molecule等工具，而不仅仅依赖于代码审查来确保Playbook的质量。

成果物的质量

如果不考虑自动化测试，测试基本上不会改变以前的方法。
我们需要确认”设计-实际设备之间的参数差异不存在”以及”所期望的功能能够实现”。
然而，如果使用Ansible，需要意识到更多不再必要检查的过程，例如在实际设备上确认参数设置正确的过程，这样我们可以减少之前频繁进行的操作。

以实际运行Playbook并通过单元测试确认服务器参数全部正确的情况为例，以下内容应得到保证。

1. Playbook的处理是正确的（参数被设置在目标位置上）

1. Playbook中所写的参数是正确的

在实际设备上设置的参数是正确的

考虑到从这里开始更改参数时，需要每次确认第二点的正确性。但是，每次都需要确认第三点吗？我认为不需要。
在确认了第一点的正确性之前的独立测试中，“第一点是正确的”，“第二点已经确认正确”这样的前提条件下，如果Playbook的执行结果正常结束，那么我们可以认为根据Ansible的幂等性，第三点会自动得到保证。
人工手动进行变更时可能存在人为错误，所以每次都应该进行第三点的测试。但是，如果使用Ansible进行构建，机器应该不会发生此类错误。
当然，如果不放心，可以进行实际设备的确认，但一般来说，这个步骤基本上是多余的。
如果想明确确认第三点，可以执行dry-run，并再次确认Playbook的内容已经正确地反映在实际设备上。

资源

在这里所说的资源，并不仅仅指物质上的东西，更指的是人类（PJ成员）。

获取资源

当然，如果可能的话，最好能确保有了解Ansible的人才，但其实Ansible本身就是被设计成易学易写的，所以只要没有对字符串有过敏感，我认为掌握它是可能的。
与其从一开始就确保精通Ansible的人才，不如制定成员培养计划更为重要。

团队的培养

就育成的观点而言，我们应该制定更具远见的计划，不仅仅关注Ansible的技术问题。
在自动化团队中，我个人认为被要求的是识别“浪费”的能力。
如果能够持续地提出对现有设计和流程的质疑，并培养出能够想出/实现更高效方法的团队就太好了。

交流

我认为使用Ansible进行沟通没有什么需要注意的事项。
如果团队之前没有使用过Git，那么在代码审核方面可以在Pull Request上进行交流，就这么简单吧…

风险

日程风险

关于日程安排，与之前的做法大有不同。特别是在构建阶段，启动的时间延迟，并且期间缩短，这是需要制定风险应对计划的地方。

变更风险

使用Ansible相比传统的方法，可以加快对变更的处理速度。以往我们需要手动在实际设备上进行参数修改，而使用Ansible只需在“Playbook内修改参数并重新运行”，变更就能机械化地反映出来，并且通过使用Git可以自动进行参数变更的版本管理。由于这个过程被工具简化了，因此可能大大加快响应速度。

成本风险

如果能够理解使用Ansible的影响，通过承认由此带来的附加范围作为利益，可能会带来与销售增长相关的正面风险。

采购

关于采购，我没有特别的想法！

利益相关者

在当今备受关注的数字化转型（DX）领域中，Ansible可以成为引导基础设施建设走向DX的重要要素。如果能够确定这方面的利益相关方，并促进他们的参与和支持，将成为一个巨大的优势。