![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2024-04-17T11:50:13+09:00","default:irrp","irrp") #author("2024-04-23T14:26:37+09:00","default:irrp","irrp") →IaC(Infrastructure as Code) →テスト・品質管理 →インシデント管理ツール →ディスク関連ツール →ネットワーク関連ツール #contents *サブトピック [#ec1a4420] -[[SRE/DevOps]] *一般 [#j4f563bd] -[[大規模サービスのインフラを全面的にリプレイスした話 #AWS - Qiita>https://qiita.com/poly_soft/items/c71bb763035b2047d2db]] 2024.4 -[[5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる>https://syu-m-5151.hatenablog.com/entry/2024/04/16/180511]] 2024.4 -[[GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる − Publickey>https://www.publickey1.jp/blog/23/github1200mysql_5780.html]] 2023.12 -[[ここが変わったよ！ 運用設計の教科書｜近藤 誠司>https://note.com/sekondo/n/n619e402e1e3b]] 2023.8 -[[AWS Backupを使ってEC2のバックアップの設定を行い、ついでに復元までやってみた | DevelopersIO>https://dev.classmethod.jp/articles/aws-backup-for-ec2/]] 2023.8 -[[ソフトウェアはなぜバージョンアップしなければならないのか - Qiita>https://qiita.com/autotaker1984/items/a3091772dbb0fb91473d]] 2023.7 -[[システム運用はお金で解決したい、ができなくなってきている - orangeitems’s diary>https://www.orangeitems.com/entry/2023/07/14/120000]] 2023.7 -[[明日クラウドサービスが停止しても慌てないための「5つの対策」 ISMS規格改訂で考慮事項に (1/3)|EnterpriseZine（エンタープライズジン）>https://enterprisezine.jp/article/detail/17903]] 2023.6 -[[厳格なルールを実装した結果、大変な状況になったデータセンターを見たことがある - 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を前提にさらに拡張したイメージ -[[エンジニアなら知っておきたい障害報告&再発防止策の考え方>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度くらいの頻度でテストすることは可能だろう。札付きシステムはもちろん，優良システムであっても，定期的なチェックを欠かしてはならない。 *問い合わせ対応／ヘルプデスク／サービスデスク／インシデント管理 [#i5c64716] →インシデント管理ツール -[[カスタマーサポートだけど、開発チームに敬意が持てない>https://anond.hatelabo.jp/20230629233830]] 2023.6 -[[インシデント管理とは何か。そして、解決のためには何をすべきか。>https://qiita.com/flyaway/items/b42118088d153812ad1b]] 2021.9 --インシデント管理の目的は、恒久対策ではありません。 --下記のような達成目標は、問題管理として分けて実施すべきものです。 インシデントとなった原因の追及と対策 エラーに基づくインシデントの再発防止 予防的な問題管理の実施 *全銀システム障害問題 [#hc4453b1] -[[「全銀システム障害」とは何だったのか 解明まで時間がかかった理由と、待ち構える“茨の道”とは（1/5 ページ） - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2312/28/news104.html]] 2023.12 -[[すべてのフェーズでミスが重なった ―全銀ネットとNTTデータ、全銀システム通信障害の詳細を説明 | gihyo.jp>https://gihyo.jp/article/2023/12/zengin-nttdata]] 2023.12 -[[全銀システム障害とは何だったのか【鈴木淳也のPay Attention】-Impress Watch>https://www.watch.impress.co.jp/docs/series/suzukij/1551556.html]] 2023.12 -[[全銀ネット障害、原因は仕様の”見落とし“ 設計者がチェックしていれば防げた可能性も - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2312/01/news179.html]] 2023.12 -※仕様の見落としというより、OS変更で32bit→64bitへのアーキ変更によって必要な領域サイズが変わるということを問題として認識できなかった、あるいは4テーブル合計サイズで計算しなければならないことを認識できていなかった（仕様認識の漏れ）か？ -[[【LIVE】NTTデータと全銀ネットの両トップが会見 10月のシステム障害受けて（12月1日）| TBS NEWS DIG>https://www.youtube.com/live/1WvRPuNfbFs?si=iwQ5iyyq9umkP21P&t=634]] 2023.12 -[[全銀システム障害の真因はメモリーの確保領域不足、全銀ネットとNTTデータが発表 | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/news/18/16364/]] 2023.12 -[[全銀システムの大規模障害、「真の原因」明らかに--全銀ネットとNTTデータが発表 - CNET Japan>https://japan.cnet.com/article/35212251/]] 2023.12 -[[全銀システム障害に残る3つの謎を追う、生成AIには負けられない | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/column/18/00138/111401408/]] 2023.11 -[[全銀ネット障害、根底に“開発体制の不備”か NTTデータの見解 - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2311/07/news129.html]] 2023.11 -[[全銀システム障害、全銀ネットの対応で不足していたもの【鈴木淳也のPay Attention】-Impress Watch>https://www.watch.impress.co.jp/docs/series/suzukij/1542501.html]] 2023.10 -[[全銀ネット障害、いまだ根本原因特定できず メモリ不足の指摘には「分からない」 - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2310/18/news179.html]] 2023.10 -[[システム障害に係る対応状況について>https://www.zengin-net.jp/announcement/pdf/announcement_20231018_2_besshi.pdf]] 2023.10 -[[プログラムミスで容量不足 全銀システム障害|47NEWS（よんななニュース）>https://www.47news.jp/9999417.html]] 2023.10 -[[全銀システム障害の原因判明、メモリー不足でインデックステーブルが不正確な状態に | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/news/18/16109/]] 2023.10 -[[2029年まで続く『全銀システム』リスク。次回は2024年1月に計画（神田敏晶） - エキスパート - Yahoo!ニュース>https://news.yahoo.co.jp/expert/articles/07e605145d5fa1ca5ac95d9b741bdb53c91f623c]] 2023.10 -[[全銀システム障害と、同システムが目指す将来像【鈴木淳也のPay Attention】-Impress Watch>https://www.watch.impress.co.jp/docs/series/suzukij/1538720.html]] 2023.10 -[[「テストを当然実施してきた」、全銀ネットが10日に開催した説明会の一問一答 | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/column/18/00001/08495/]] 2023.10 -[[全銀システムの大規模障害、中継コンピューター2台ともに不具合で冗長構成が機能せず | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/news/18/16078/]] 2023.10 -[[全国銀行データ通信システムのシステム障害についてまとめてみた - piyolog>https://piyolog.hatenadiary.jp/entry/2023/10/11/131415]] 2023.10 -[[全銀システムで中継コンピューターのチェック機能に不具合、40万件が処理できず | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/news/18/16074/?i_cid=nbpnxt_sied_blogcard]] 2023.10 -[[50年間も動き続けていた全国銀行資金決済ネットワークがシステム障害で振込処理ができない状態になっている「これはヤバい」「給料が振り込まれない」 - Togetter>https://togetter.com/li/2239071]] 2023.10 *ファーストサーバ事故関連 [#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] -[[JP1/AJS3から実行されるジョブ実行時に設定される環境変数>https://itpfdoc.hitachi.co.jp/manuals/3020/30203s1033/AJSO0027.HTM]] 2024.2 -[[5.1.1 実行エージェント : JP1/Automatic Job Management System 3 導入ガイド>https://itpfdoc.hitachi.co.jp/manuals/3021/30213d2120/AJSF0091.HTM]] 2023 -[[[JP1/AJS3]ややこしい単語たちの整理（カレンダーvsスケジュールvsスケジューラーサービス） - Qiita>https://qiita.com/yukitsuboi/items/46873a952f6b31bf77ff]] 2022 -[[JP1/Automatic Job Management System 3 入門 - 目次>https://itpfdoc.hitachi.co.jp/manuals/3020/30203S0133/AJSZ0001.HTM]] 2023 -[[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 -[[10分で理解するGrafana - Qiita>https://qiita.com/Chanmoro/items/a23f0408f0e64658a775]] 2018 -[[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] -[[情シス359人に聞く業務課題、2位は「人材が足りない」 1位は IIJ調査 - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2312/27/news149.html]] 2023.12 -[[情報システム部門を増員する企業が増加傾向に、IIJが調査 | TECH+（テックプラス）>https://news.mynavi.jp/techplus/article/20231109-2814726/]] 2023.11 -[[情シスのお仕事って、とても報われにくい仕事なんじゃないか - 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割の企業で情シス職の採用が難航している一方で、半数以上の企業がパートナーを今後、積極活用したいと思っていることが今回の調査で分かったとしている。
