#author("2023-05-09T12:01:48+09:00","default:irrp","irrp")
→IaC(Infrastructure as Code)
→テスト・品質管理
→インシデント管理ツール
→ディスク関連ツール
→ネットワーク関連ツール
#contents
*サブトピック [#ec1a4420]
-[[SRE/DevOps]]
*一般 [#j4f563bd]
-[[厳格なルールを実装した結果、大変な状況になったデータセンターを見たことがある - orangeitems’s diary>https://www.orangeitems.com/entry/2023/05/09/000000]] 2023.5
-[[トラブルシュートの進め方 - まつざっきブログ>https://blog-smatsuzaki.hatenablog.com/entry/2022/07/09/110754]] 2022.7
-[[「システム運用アンチパターン」を一読したので、その要点（特に薦めたい感想5点） - Qiita>https://qiita.com/e99h2121/items/5327cda822b8ea588169]] 2022.4
-[[バックアップを取ること自体に、リスクがあるという現実 - orangeitems’s diary>https://www.orangeitems.com/entry/2021/12/29/131550]] 2021.12
-[[「SIAM入門」連載一覧>https://enterprisezine.jp/article/corner/474]] 2019
--SIAMはITILを置き換えるものではなく、ITILを前提にさらに拡張したイメージ
-[[インシデント管理とは何か。そして、解決のためには何をすべきか。>https://qiita.com/flyaway/items/b42118088d153812ad1b]] 2021.9
--インシデント管理の目的は、恒久対策ではありません。
--下記のような達成目標は、問題管理として分けて実施すべきものです。
インシデントとなった原因の追及と対策
エラーに基づくインシデントの再発防止
予防的な問題管理の実施
-[[エンジニアなら知っておきたい障害報告&再発防止策の考え方>http://qiita.com/hirokidaichi/items/f9f4549c88aaf8b38bda]] 2014.1.19
-[[クラウド時代のデータセンターが持つ理想と現実>http://thinkit.co.jp/story/2012/06/13/3583?page=0,0]] 2012.7.7
-[[ログローテーションとは…>http://cyberam.dip.jp/linux_foundation/systemlog/logrotate_main.html]]
--[[logrotateの不思議！ >http://www.kozupon.com/logrotate/logrotate.html]]
--[[logrotateでログファイルがローテーションされない事への対処>http://ameblo.jp/itboy/entry-10027962914.html]]
-[[ゼロからはじめるバックアップ入門>http://ascii.jp/elem/000/000/489/489364/]]
-[[IT現場の災害対策>http://itpro.nikkeibp.co.jp/article/COLUMN/20100304/345374/]] 2011.3.25
--[[重点はシステムから人へ>http://itpro.nikkeibp.co.jp/article/COLUMN/20100304/345386/]]
--[[課題1 その手順書が操作ミスや遅延を招く>http://itpro.nikkeibp.co.jp/article/COLUMN/20100304/345387/]]
--[[課題2 連絡網が機能しない時もある>http://itpro.nikkeibp.co.jp/article/COLUMN/20100308/345481/]]
--[[課題3 自宅で必要なデータを入手できない>http://itpro.nikkeibp.co.jp/article/COLUMN/20100308/345504/]]
--[[課題4 別の人が業務を継続できない>http://itpro.nikkeibp.co.jp/article/COLUMN/20100308/345505/]]
-[[災害にあったITシステムを操作しなければならない人が知るべきこと>http://www.publickey1.jp/blog/11/it_14.html]] 2011.3.14
-[[組織が運用SEのやる気を削ぐ >http://itpro.nikkeibp.co.jp/article/COLUMN/20090323/327040/]] 2009.10.19
--このシステム子会社では「優秀な人材は開発担当に，そうでない人材は運用担当に」という周知のルールがあり，評価や処遇にも差があった。20代後半に運用部門に配属された山崎氏は，自信とやる気を失い，学習意欲もなくなった。これではスキルも向上せず，本来やるべき仕事もこなせない。
-[[「問題がない状態」=「普通の状態」って判断されることが、システムの悲劇の様な気がしたあの日。>http://mubou.seesaa.net/article/72063013.html]]
--電気は流れているのが当たり前、水道は蛇口を捻れば流れ出すのが当たり前、電車は定刻通りに動いているのが当たり前であって、止まればそれは「異常事態」なのが日本と言う社会な訳だが、実際の所インフラをインフラとして運用するだけでも、コストはかかるし腕も要る。
--システムなんぞ何をかいわんやで、元来「不安定な状態」がデフォルトかと思いたくなるくらいインフラとしては未成熟なのに、向けられる期待値は社会基盤のインフラに向けられるそれとあんまり変わらない様な気が、時折する。
--構図としては、「健康のありがたみ」がどうとかいう話に似ている気がする。健康であり続ける為にもコストはそれなりにかかるのだが、そのコストに気付く為には病気にかかる必要がある。
-[[社内のIT資産を一元管理するi-doIT>http://www.moongift.jp/2008/06/i-doit/]]
-[[安定稼動のシステムこそ危険>http://itpro.nikkeibp.co.jp/article/COLUMN/20080117/291336/]] 2008.4.7
--普段から障害ばかり起こすシステムと，数年にわたって1度の障害もなく安定稼働を続けているシステムでは，いざトラブルが起きると前者よりも後者のほうが大規模かつ悪質なケースが多い。
--システム部門は札付きシステムや札付きプログラムを，たびたび障害を引き起こす“犯人”としてマークする。しかし，最も恐ろしい障害は，マークしていたシステムやプログラムではなく，意外とノーマークのシステムやプログラムによってもたらされるものだ。
--すべての人間に強制的に検診を受けさせるのは難しいが，システムの場合は時間と体力をそれなりに費やす覚悟さえあれば，1年や2年に1度くらいの頻度でテストすることは可能だろう。札付きシステムはもちろん，優良システムであっても，定期的なチェックを欠かしてはならない。
*ファーストサーバ事故関連 [#a4a96c16]
-[[データ消失！あのとき、ファーストサーバになにが起こったか？>http://ascii.jp/elem/000/000/913/913202/]] 2014.7.27
-[[大規模障害から1年余り、あの企業が「その後」を語った>http://itpro.nikkeibp.co.jp/article/Watcher/20140214/536882/?ST=security&P=1]] 2014.2.20
-[[「軽過失だが比較的重度の過失」とは？ 法律家が読み解く、ファーストサーバ事件報告書>http://jibun.atmarkit.co.jp/lskill01/rensai/law/02/01.html]] 2012.8.9
-[[ファーストサーバ、データ消失事故の再発防止策を発表>http://www.itmedia.co.jp/news/articles/1208/10/news051.html]] 2012.8.10
-[[6月20日から21日にかけて発生した一連の事故の再発防止策>http://support.fsv.jp/urgent/fs-report.html]] 2012.8.10
-[[ファーストサーバ最終報告書、ベテラン担当者のマニュアル無視を黙認 >http://itpro.nikkeibp.co.jp/article/NEWS/20120731/413084/?ST=cloud&P=1]] 2012.7.31
--[[「ファーストサーバ最終報告書、ベテラン担当者のマニュアル無視を黙認 」>http://d.hatena.ne.jp/JavaBlack/20120801/p1]] 2012.8.1
---おそらく問題認識が間違ってる．まるでドライバー一人で長距離バスを24時間連続運転させておきながら，ひとたび事故が起きれば「ドライバーの運転ミス／居眠り運転が原因です(キリッ)」と言うような感じ．その場合の事故の責任はドライバー以上に経営者にある．
---対策においても「バックアップディスクへの変更について，明確に禁止した条項がないことから追加し，バックアップディスクの更新禁止を明確化する」とか書いてる時点でダメダメ．禁止を条項に書いたらコマンドの打ち間違いによる人的ミスが無くなるとでも？そういうのは全部ツールを作って，削除の禁止をツールの中に作り込んで，そのツールを使う限りどんなバカでもハッカーでも削除できないようにしておくんだよ．そもそもバックアップディスクが普通に物理的に触れるような場所に接続されてること自体が問題だろうし．
-[[第三者調査委員会「 調査報告書 （ 最終報告書 ） ＜ 要約版 ＞ 」>http://support.fsv.jp/urgent/pdf/fs-report.pdf]] 2012.7.31
-[[緊急特集：ファーストサーバ社データ消失事故の教訓（２）クラウド技術は全体最適の視点がないと難しい −ITアーキテクト・鈴木雄介氏>http://wirelesswire.jp/Inside_Out/201207241630.html]] 2012.7.24
-[[ファーストサーバの事故から考えること >http://shunichi-arai.blogspot.jp/2012/06/blog-post_25.html]] 2012.6.25
--致命的ミスと言えるのは、待機系(スタンバイ)サーバと、バックアップを混同してしまっていたことだと考えられます。
--待機系サーバというのは、あるサーバが故障で動かなくなったさいに代わりに立ち上げるサーバであり、そのデータは常に本番環境と同じデータを保持している必要があります。そのため、本番環境で行われたオペミスなどは待機系サーバにも波及してしまいます。
--それに対し、バックアップというのは、基本的には「ある時点のデータ」を保存して、オペミスを含むデータ損失事故を防ぐというものです。
--これはIT技術者にとって基本的知識だと思われますが、その点の配慮が無かったことが最大の敗因でしょう。
-[[大規模障害の概要と原因について（中間報告）>http://support.fsv.jp/info/nw20120625_01.html]] 2012.6.25
--ファーストサーバ大規模障害の報告
-[[ソフトバンクグループのファーストサーバがバックアップ含めデータ全消失、復旧不可能確定。 >http://nosoftbankno.blog84.fc2.com/blog-entry-177.html]] 2012.6.15
*運用支援/監視ツール [#q822a281]
-[[Mackerelで作るダッシュボード事例 Amazon RDSへの移行を確認する - Hatena Developer Blog>https://developer.hatenastaff.com/entry/2023/01/27/093000]] 2023.1
-[[【やってみた】Zabbix6.0の構築 EC2+RDS - サーバーワークスエンジニアブログ>https://blog.serverworks.co.jp/shiz/zabbix6-install-with-ec2-rds]] 2022.9
-[[IT資産管理をオープンソースだけでやってみたメモ（OCS Inventory NG + GLPI）>https://qiita.com/nagase/items/c3a6184dd1a56e2ed34d]] 2017
-[[複数サーバを一括監視しCPU/メモリ/ディスクなどをチェックできるフリーソフト「ManageEngine Free Windows Server Monitoring」>http://gigazine.net/news/20120718-free-windows-health-monitor-tool/]] 2012.7.18
*情報システム部門の仕事 [#wafe251b]
-[[情シスのお仕事って、とても報われにくい仕事なんじゃないか - orangeitems’s diary>https://www.orangeitems.com/entry/2023/04/29/120000]] 2023.4
**ひとり情シス問題 [#ef8b7424]
-[[社内にIT人材「いない」7割、人材育成「難しい」6割（時事通信） - Yahoo!ニュース>https://news.yahoo.co.jp/articles/8b18eda7b9b314c6e067ad7eb4d321c06a4286cf]] 2023.3
-[[知りたくなかった数字で見える【ひとり情シスの実態】｜SHIFT Group 技術ブログ｜note>https://note.com/shift_tech/n/n5da38fc26304]] 2023.2
-[[ASCII.jp：一般社団法人 ひとり情シス協会、「ひとり情シス実態調査」&「中堅企業IT投資動向調査」の速報値を報告>https://ascii.jp/elem/000/004/081/4081487/]] 2022.1
--従業員数100名〜500名のひとり情シス企業は32％と昨年より微増した。しかし、58％のひとり情シス企業で昨年を大きく上回る増員意向を持っている実態が判明している。
--ベテランひとり情シスの定年退職や転職などの後任として、情シス経験の浅いひとり情シスが増加しており、ひとり情シスの24％が3年未満の経験であることが判明したという。
--7割の企業で情シス職の採用が難航している一方で、半数以上の企業がパートナーを今後、積極活用したいと思っていることが今回の調査で分かったとしている。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
