構築中。

名古屋のITインフラ屋さんです。ITイベントへの参加記録などを残していきます。

切れ味鋭い名刀でなくて100均のペーパーナイフでも素手で戦うより何倍もマシな件

タイトルが回りくどい。

先のエントリの通り、現在とあるシステムの移行準備中です。

 

本日、若手メンバーが新しい仮想サーバにユーザ登録をしていたのですが…対象が10サーバほどあり、登録すべきユーザも10人近くいたにもかかわらず、

「すべて手作業」

で黙々と進めておりました。

私がそれに気づいたのが、定時退勤時間を過ぎた18時ちょっと過ぎあたり。職場ルールで20時には強制退勤となるので、本日の残り時間は長くてもあと2時間弱。

その時点で、10サーバ中6サーバ目が終わる間近、そこまでに至る経過が、ざっくりと

・作業方法の調査、ユーザのキーペア発行などの準備作業で約1時間

・実際のユーザ登録が1サーバあたり約30分(!)

てな感じで、4時間ほど黙々と作業を続けており、あと残りは2時間ぐらい…という「今日中に終わるかどうか微妙な」ライン。

後の予定の関係で、終わらなければ明日の土曜出勤が確定します(ちなみに私は別の作業があるのですでに出勤確定しております)。

 

たったそれだけのことで出勤させるのもかわいそうなので、強制的に手を止めて、

・本人にも理解可能なExcelを使って

・セルの式で各ユーザに合わせた引数を持つコマンドを生成して

・セルをコピペすればbashスクリプトになるように

作業を進めてもらったところ、変に恰好をつけて(コマンドなどの)固定の文字列部分もセルに記述しそれを参照するように式を作り始めたせいで、セル参照の固定($)が行方向と列方向で混在し、(当人が)混乱してかなり手間取ったものの、

・約30分でシェルスクリプトは完成し(恰好をつけずに文字列定数で式を作れば所要時間はせいぜい5分か10分だったはず…)

・1サーバあたり5分以下でユーザ登録が完了した

ので、無事、土曜出勤を回避することができました。

※サーバとユーザがそこそこの数あるなら最初からディレクトリサービス使えよ、という声も聞こえてきそうですが。

 

また、ついこの間、私が振休を取って秋葉原に行っていた日には、もっと業務歴の長いメンバーが、レコードのエクスポート/インポートが可能にもかかわらず、DNSのゾーンを(数十レコードある!おまけに長いTXTレコードも複数!)数時間かけてすべて手作業で入力して移行していたことがあったようで。

エクスポート/インポートすれば30分で終わったのにね。あーあ。

 

何も高度なツールを使いこなさずとも、だれでも使えるようなツールで低レベルなことをするだけでも、数倍のスピードアップとそれ以上の労力の削減ができるはずなのですが(一所懸命画面で間違いがないか確認しながらひたすらキーを打つ、というのはとてもツラいでしょうに)。

※ついでに、ツールを使うときに変に恰好をつけるのもやめましょう。

 

「結果よりも一所懸命やっている姿を見せることが大事」といわんばかりの行動ですが、こういうことが度々あるということは、当人たちだけの問題ではなくて、周りで彼らを見ている人たちの問題でもあるのかもしれません。

一度きりの作業でも「Infrastructure as Code」

…いや、実際に「やっている」という話ではないのですが。

 

今、とあるシステムの移行を進めているのですが、「人力作業用」の手順書が…すでに4~5テイク目というのに、出るわ出るわ、もりもりと。

といっても、Gitの「うんこもりもり」ではなくて…未だに致命的な手順の間違いがもりもり出てきます。

作っている当人は「ちゃんと見直して間違いがないことを確認しました!」と言ってましたが(私が「本当に大丈夫だよね?」と煽ったので半ばキレながら…)、作業1項目めから既にタイポがいくつか。

…ああ、頭がくらくらする。

人がすることなので、「実際にその手順書に沿って手を動かしてみないと本当に手順通り実行できるかどうかわからない」のは、ある程度仕方がないのですが。

 

というわけで、やっぱり「システム移行のような『一度しか本番利用しない』作業もコード化する」のが1つの解なのかな、と思います。

デバッグは大変ですが、一度完全に動いてしまえばケアレスミスで失敗する確率もかなり低くなりますし、「作業本番になって初めて手順のミスに気付いて詰む」ということもなくて、精神衛生上よろしいかと。

エラーリカバリとかが考えられていなかったり雑だったりすると、コードが止まった時にかえって焦る可能性もありますが、「事前にデバッグできる」というのは大きな強みです。

 

もちろん、人力でも、大事な作業の前にはリハーサルをして手順書の問題点を可能な限り洗い出すのですが…それでも、本番と心理状態は違う上に、一度通すのにそれなりの時間と負荷がかかりますし、そこで出た指摘が全て修正されずに間違いが残ってしまう可能性もあります。

実際、今回、目視チェックの4~5テイク目でも、以前指摘した事項が修正されずにそのままいくつか目の前にやってきましたから…。

 

そういえば、はてなのMackerelでも、少し前にシステム移行で障害を発生させていましたね…。

mackerel.io

我々のような弱小(ザコ)部隊ではなくプロがそろった現場でもこうなる(こともある)ので、相当気を引き締めて実行しないと。

※話はそれますが、こうやって「事故」を詳細に報告してもらえるのはありがたいです。最近メルカリのCDN絡みの事故がありましたが、他社からのものも含めて、このような情報がミスや勘違いの発見・防止にすごく役立っています。

 

とかくシステム移行は「移行がゴール」という気持ちで、移行直前は駆け込みでタスクを「淡々とこなす」「やっつける」となりがちですが、本当は「移行がスタート」なので、移行準備の間に知見を蓄えてサービスインするぐらいの気持ちでないと、移行後に地獄が待っていることもあります(数年前、実際に「事件」が起きてロールバックしましたが)。

AWS Solution Days 2017 ~セキュリティ&コンプライアンス~(8/9・その3)

その2の続きです。

AWS Solution Days 2017 ~セキュリティ&コンプライアンス~ (2017 年 8 月 9 日開催) | AWS

午後の後半3つのセッションについての感想などです。

 

AWS コンプライアンスの先進性(Henrik Johanssonさん)

コンプライアンスには証跡収集が大事、特にイノベーションによって変化が加速した現在では、コンプライアンスのスコープもどんどん変わっていくので、証跡の取得を自動化して、さらに是正の自動化も行っていくことが大事(コンプライアンスの自動化)、というようなお話でした。

前のセッションでのリファレンスアーキテクチャの1つ目の例と似ていますが、CloudWatchのイベントをLambdaを通してDynamoDBに集めるとともに、それがセキュリティ違反・コンプライアンス違反の行為によるイベントであり、複数回繰り返されたものであれば、当該ユーザーの権限を自動的にはく奪する、というソリューションが例示されました。

そのほかにも、Step Functionsを組み合わせてLambda単体よりも複雑なことをさせたり、Machine Learningを組み合わせて判定したり、などなど。

もちろん、CloudTrailやConfig (Rules)への言及もありました。

 

その他、AWS内部でのベータテスト中のサービスとして、「Tiros」「Zelkova」という名前が出てきました。

Tirosは、AWSネットワークの到達性の確認を、PING等のパケットを飛ばすことなく確認するもので、現在はCLIのみのサポートだそうです。

ここで話題に上がっています。

What are your current unmet AWS security needs : aws

AZ、EC2等のインスタンス、Internet Gateway、ELBなどの要素が対象で、タグを判別してルールを適用(例:特定のタグを付けずにインスタンスを起動したままにしておくと、1時間で強制停止)する、といったことができるようです。

つまり、構築時のチェックだけでなく、運用中に加えられる変更について、コンプライアンスが守られているかについてのチェックにも使える(というかこちらが主目的)、という機能です。

IAMについても、同様にポリシーがどう働くか確認できる機能が開発されている、という話でしたが(同時通訳の方が単語を読み間違えた模様なのと検索しても情報を見つけられなかったので)Zelkovaのことを指しているのかどうかは不明です。

※Zelkova、正確に言うとZelkova serraは「ケヤキ」ですが、「serrata」が「errata」にかかっているのか、AWSの中の人に欅坂46のファンがいるのか、そもそも「Zelkova」なんていうサービスはない(私がスクリーンを見間違えた)のか、真相は不明です。

個人的には、このあたりの開発中の機能についての説明が、今回の一番の収穫でした。

 

また、コンプライアンスレポートポータルとして、Artifactが紹介されました。

なお、Artifactはこの後のセッションでも度々言及されていました。

 

医療情報のセキュリティ保護に向けて(上島努さん)

医療機関向けクラウドサービス対応セキュリティリファレンスのAWS対応版についてのお話でした。

Azureについてはすでに公開されていますが(なので日本の医療機関の取り込みはAWSよりAzureが先行しているように見えます)、AWSはアメリカのHIPAAなどには対応しているものの、日本では同じ分野についての対応確認が遅れているので、現在頑張って進めています、ということです。

例えば、国内法に関する要求事項に対応するために、AWSでは

・準拠法を国内法に変更する(今年、AWS Summitか何かで長崎社長がこの点について言及されていました)

・東京リージョンを使用する

というようなことが必要、というようなことが策定中のリファレンス(案)で示されています。

年末を目標に策定中、とのことでした。

 

クラウド利用時のアーカイブデータのセキュリティ(Ken Beerさん)

クラウドでのデータ保護について、静止中(ディスク上)、移動中(ネットワーク上)、利用中(メモリ上)の3つに分類→それぞれに対するアクセスコントロールや保護の設定を行う→モニタリングする→コンプライアンスレポートを出力・確認→最初に戻り、繰り返す、というようなお話でした。

暗号化をアクセスコントロールの一種として考えること、クラウド環境における鍵管理の問題(クラウド管理者側で鍵を悪用できるのでは?)とその解決のために選べるいくつかのレベルのソリューションとしてのKMS(CloudTrailとの連携、KMS assurances)について、第三者認証(SOC 1/2/3、PCI-DSSなど)、フェデレーション、自社Webサービスのアクセスコントロール方法、モニタリング、レポートなどが解説されました。

 

内容は盛りだくさんだったのですが、前のセッションで話されたことや自分自身すでに知っていることが多かったので、細かい内容は省略します。

 

 

普段エンジニア目線でAWSに接している身には、ちょっと難しめのテーマでしたが、強引?に休みを取って参加した甲斐はあったと思います。

 

…その2に書いたとおり、翌日が大変でしたが…(もっと大変なのは多分盆休み明け…)。