Infrastructure as Codeのつらみの原因を探れ 恐怖症による負のサイクルを断ち切る“予測可能性”
ソフトウェア開発、ITインフラ運用、そしてその境界線上にあるトピックをカバーし、特にDevOpsを実現するための自動化、テスト、セキュリティ、組織文化にフォーカスした「DevOpsDays」。ここでソフトウェアエンジニアのチェシャ猫氏が「Infrastructure as Code の静的テスト戦略」をテーマに登壇。まずはInfrastructure as Codeについてと、そのつらみから発生する“オートメーション恐怖症”を防止する方法を紹介します。 「コード化の“つらみ”をいかにうまく防ぐか」が今日のテーマ チェシャ猫氏：チェシャ猫と言います。Twitterは@y_taka_23の名前でやっているので、よろしくお願いいたします。今日は「Infrastructure as Code の静的テスト戦略」をテーマに選びました。Infrastructure as Codeはここ数年で、非常にメ
政府や自治体のシステムが今までどうなっていて今後どうなるかをできる限り簡単に説明してみる - orangeitems’s diary
政府や自治体のシステムって、縦割りでベンダーに丸投げするから無駄が多くて、税金から払わなくてもいいお金が一杯出て行っている。しかも国民から見るといっぱいサイトがある割にはどれもデザインが違っていて、さっぱりどこ見ていいかわからない。どうなってんの。 ここがまず国民の不満の出発点だと思うんですね。 そしてクラウドなる新しいITの利用が一般化してきていて、政府や自治体も積極活用しようということになりました。ただその話が出てきたのが2012年でそのときはAWSすらまだ数あるサービスの一つだったこともあり、国内ベンダーに、政府共通プラットフォームなる基盤を作らせて2013年に利用をし始めました。クラウドと言っても、VMwareの基盤にインターネットをつないだだけです。 そして、2016年に、会計検査院からこの基盤はダメ出しを受けます。利用料が高い割にはさっぱり使われておらず、使われ方もまるで不合格
20年前の「障害の再発防止策の考え方」は今でも通用する説 - Qiita
障害の再発防止策は、 1. メカニズム 2. ツール 3. ルール 4. チェックリスト の順番に検討せよ。 上記は、私が20年前に所属していたパッケージソフト開発会社の標語です。 ※転職したので現在の所属会社ではありません。 当時はまだインターネットが今ほど普及しておらず、修正パッチはCD-Rで配布していました。 特に、データ破損系の障害の場合は、 お客様にファックスで障害内容を報告し、 緊急ホットラインを開設し、 データ異常が見られる場合はバックアップを預かって修正後に返却し、 上記と同時並行でバグの原因調査と修正を行い、 パッチをCD-Rに焼いて配布する。 という障害対応を行っていました。 各パッケージの利用社数は数万〜10数万社に上りますので、大変な騒ぎでした。 そして事後に、障害の再発防止策を検討し報告する義務が課されるわけです。 メカニズム 仕組みとして、障害原因を封じ込める対
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
