日本におけるIT自動化導入の特殊な事情 -...

1 Copyright © 2016 NTT DATA Corporation

エンタープライズ用途で“使える” IT自動化の考え方

2016年7月20日株式会社ＮＴＴデータ菅原亮

Web公開向け資料


アジェンダ

昨今IT自動化が叫ばれて久しいですが、特に旧来型の大規模プロジェクトにおいては、様々な事情によりIT自動化の導入が困難なケースが多くみられます。

本セッションでは旧来型の大規模プロジェクトに対するPuppet導入の経験を踏まえて、各フェーズごとの考え方のポイントを紹介します。

皆様のプロジェクトに対するIT自動化導入の一助になれば幸いです。

Let’s Puppetize!

- 自己紹介 -

- 課題編 -

- 設計編 -

- 開発・試験編 -

- まとめ -

3 Copyright © 2016 NTT DATA Corporation Copyright © 2016 NTT DATA Corporation 3

自己紹介


自己紹介（Self Introduction）

名前：菅原亮（すがはらりょう）

所属：株式会社NTTデータ技術革新統括本部システム技術本部方式技術部

Puppetとの出会い： 2012年にNTT OSSセンタにて自動化推進の担当になった事がきっかけです。その時にPuppetの素晴らしさを知り、世に広めたいと思いました。

OFFのわたし：シルビアで各地のショッピングモールに現れますベランダに菜園作ってますいろんな料理作ってます（もちろん片付けしてます）主にWindowsでいろんなアプリ作ってます最近電子工作にハマってます


IT自動化導入の考え方～課題


日本におけるエンタープライズのIT事情

“日本型SI”はクライアントから受注したシステム開発を個々の作業別で協力会社に発注という形態が多い

設計、構築・試験、保守・運用を担当する会社がバラバラ

多くの場合、保守・運用フェーズのメンバーはコードを読めないつまりコード化されたシステム基盤の保守は難しい

設計（A社）構築・試験（B社）保守・運用（C社）


IT自動化導入の考え方～提案フェーズ


IT自動化の目的を“正しく”考える

IT自動化はパッケージ買ってきて入れたら終わり、ではありません。

構築時間

構築台数手動構築自動構築

自動化導入時固有の作業時間

自動構築に要する時間

「IT自動化を導入したら余計コストが掛かってしまった」そんな結果にならないために…

IT自動化はあくまでも“手段” 絶対に“手段”を“目的”としない

構築するシステム基盤をコード化する作業が別途必要です。

IT自動化は魔法ではありません。


SEよ大志を抱け

コストは削減できたけど、利益も削減してしまっては意味がありません！

従来の枠に囚われず、そもそもIT自動化を使わないと

実現できないような壮大な目標を立てることが大事

「IT自動化を導入してコスト削減しましょう」～甘い言葉に潜む罠～

格言：コストの議論になったら負けかなと思ってる

コストの議論になる＝従来の枠内に収まっている従来の枠に収まっている限り、いつかはコストの議論になります。

Puppetを使って6週間で30,000ノードをたった2人で構築してみせた米ウォルマートのような壮大な夢、あなたはありませんか？

自らに問いましょう、なぜIT自動化が必要なのかを。


IT自動化導入の考え方～設計フェーズ


自動化できるのは構築だけじゃない

「構築自動化」ではなく「IT自動化」構築だけではもったいない！

保守作業で同じような作業を繰り返していませんか？

IT自動化は、むしろ保守作業に使ってこそ真価を発揮します。

対象サーバ数は“のべ台数”で考えるべし

全10サーバのシステムでも月一回の保守作業を 5年間繰り返したら…どうなりますか？

ちょっと強引な計算ですけど…

10(台)×12(回/年)×5(年)=600（台)


“日本型SI”の壁を打破せよ

IT自動化の恩恵を最大限に発揮するためには “日本型SI”の“常識の壁”を打破する工夫が必要

そんなことを考えなくて済むのが理想ですが、今は過渡期です。硬直化した現状を少しずつ壊していかなくてはなりません。

特定の機能だけでなく、チームの垣根を越えてシステム全体を見渡した設計にすべし

IT自動化はシステム全体を見渡した設計が必要です。従来の縦割り型の開発では限界があります。

どうすればチームの垣根を越えられるか？残念ながら万能な解はありません。

プロジェクトの事情に合わせた工夫をしましょう。


IT自動化導入の考え方～開発・試験フェーズ


コーディングスキルが無い“敵”は多いと心得よ

ロジックを使わない

条件分岐、ループ構造など、一目で結果を見えなくするロジック構造を極力使わないマニフェストにする

プロジェクトマネージャ、チームリーダーによるレビューなんて旧態依然な文化、無くなればいいのに…とは思いますが、まだまだ時間は掛かるでしょう。

保守作業者だけではなく、多くの場合プロジェクトマネージャやチームリーダーも多くの場合コードが読めないIT自動化の“敵”です。

Puppet言語はそのままで十分可読性が高い言語ではありますが、コーディングスキルが無い人からすれば“暗号”に見えてしまうかもしれません。

ロジックを使わず“設定ファイル感覚“で読めるようにするとコーディングスキルが無い人でも抵抗感がなくなります。

“コード”ではなく“設定ファイル”として “読めるマニフェスト”にすべし


可読性こそ命

可読性が低いコード可読性が高いコード

可読性の高いコードを書く

Puppetマニフェストは可読性が命可読性が高いマニフェストは手順書を置き換えできる

設定値が変わるたびに手順書を書き換えて作業して…面倒です。コンピュータが“手順書”を“理解”できるのなら、どんなに素晴らしいでしょう。

可読性の高いマニフェストは、これまでの操作手順書を置き換えることができます！

目指す先にあるのはマニフェストによる従来型手順書の置き換え

手順書を置き換えることができれば、マニフェストと手順書を二重管理する必要がなくなります。

さらにマニフェストはコンピュータが理解できますので、マニフェスト通りに設定されていることが保証できます。


データとマニフェストの分離

分離

マニフェストデータ

“マニフェスト”と“データ”を分離

パラメータをマニフェストから分離独立させることでパラメータ変更がマニフェスト変更につながらないようにする

マニフェストへのハードコーディングはいかなる場合も徹底して避けるべし

不幸にして理解の無い意地悪なプロジェクトマネージャがあなたの上司ならマニフェストを変更したらマニフェストの再試験を命ずるでしょう。

あなたはパラメータ変更ごときで…と思うかもしれませんが、そんな言い訳は大抵の場合通じません。

HieraやENCによる外部ソースからのパラメータ情報取得を徹底活用してパラメータとマニフェストは分離させましょう。

外部ソースを活用することにより、コーディングスキルが無い人でも保守しやすい仕組みが作れます。


“車輪の再発明”をしない

マニフェスト開発の究極形は“作らない開発” Puppet Forgeをとことん活用すべき

Puppetの強みの一つはPuppet Forgeで提供される様々なモジュール。 “車輪の再発明”はムダと心得て、徹底して活用しましょう。

真に効率化を目指すのなら、“車輪の再発明”はせず、 Puppet Forgeを活用して“作らない開発”を目指すべし

# puppet module search [keyword]

“Supported”や“Approved”のモジュールを主に利用すれば

品質も問題ありません。


本当に確認すべきことは何ですか？

“Puppetの機能試験”みたいな試験は時間のムダ何を確認すべきなのかをよく考えること

設定ファイル目視チェックの置き換えみたいな試験はムダ、システムの振る舞いを確認する試験項目とすべし

「設定ファイルの中身を確認する」という旧態依然とした試験は時間のムダ。本当に必要な動作確認は何かを考えましょう。

設定ファイルは正しいという前提でシステムの振る舞いを確認するという

発想の試験項目にしましょう。


IT自動化導入の考え方～まとめ


まとめ

壮大な目標を持つこれまでのSIerの常識に囚われない

硬直化した現状を打破する

真のIT自動化はプロセスの変革から

議論の行き着く先はプロセスの変革 Let’s puppetize!

日本におけるIT自動化導入の特殊な事情 -...

Technology

Transcript of 日本におけるIT自動化導入の特殊な事情 -...