2024.3.22（金） SRE観点での技術負債 懺悔会 2024 https://mixi.connpass.com/event/312191/
家族アルバム みてねで直面してきた技術的負債 / MIXI KAG 2024
2024.3.22（金） SRE観点での技術負債 懺悔会 2024 https://mixi.connpass.com/event/312191/
システム保守運用を丸投げしてきたツケ、委託先がセキュリティー対応を拒否
数多くのモダナイゼーション案件をみてきた筆者の経験から、実際に起こり得る問題や葛藤を架空の事件簿として解説する本連載。今回は、20年以上アウトソーサー（委託先企業）にシステムを任せてきた大手小売業A社が、脱メインフレームプロジェクトに取り組んだ事例を紹介する。 A社は1980年代のシステム導入当初からメインフレームを利用してきた。そして1990年代後半。バブル崩壊後の経済低迷や「2000年問題」対応のためのアプリケーション修正、社員採用の抑制などが重なり、A社は苦しい状況に陥っていた。そこで、コスト削減と社員不足解消のために、インフラとアプリケーションについてはメインフレームメーカーが提供するアウトソーシングサービスを利用する契約に切り替えた。 それから20年がたち、2020年に開催予定だった東京オリンピックに向けてクレジットカードのセキュリティーを強化することになった。そのためには、クレ
サイバー事故に関し システムベンダーが負う責任： 医療DXを推進するために | 日本医師会総合政策研究機構
堤 信之 ＜概略＞ 数あるサイバー攻撃の中でも、特定の攻撃手法が既に広く世間に周知され、かつ実際に被害も頻発しているようなケースでは、当攻撃手法に関し、システムベンダーは医療機関等に対し、委託契約又は信義誠実の原則に基づく付随義務として、医療機関等が患者に対する安全管理義務を履行するために必要な情報を適時適切に提供する義務を負うと考えられる。 従って、医療情報システムに設置されたFortinet製VPN装置（CVE-2018-13379）の脆弱性を突いたサイバー事故が医療機関に発生した場合、たとえ医療機関とシステムベンダーで締結したシステム保守契約において、当リスクにかかるシステムベンダーの情報提供義務が明記されていなかったとしても、当該装置の脆弱性に関する情報提供がなされていなければ、医療機関からシステムベンダーに対し、「信義誠実の原則」違反を理由に一定の責任を問える可能性がある。
ソフトウェアはなぜバージョンアップしなければならないのか - Qiita
はじめに 社内インフラの運用担当者にとってソフトウェアのバージョンアップは地味な割に大変な業務です。 特に社内のオンプレサーバで動いているようなソフトウェアの場合、バージョンアップに伴う諸々の調整をそのソフトウェアを利用している各部署と行う必要があります。 そんなときに「今は忙しいからバージョンアップを先送りしてほしい」「このバージョンはスキップしてもよいのでは？」なんて声が各部署から聞こえてきます。バージョンアップの価値を各部署に理解してもらうのは大変です。 この文章はそんな時になぜバージョンアップしなければならないのかを上司や各部署のマネージャに伝えるために書きます。 ソフトウェアの有効期限は2-5年 まず、第一に、ソフトウェアというものは無限に使えるわけではなく、一定の有効期限があり、それを過ぎると徐々に動かなくなってきます。俗にいう「何もしてないのに動かなくなった問題」です。 なぜ
わたしたちにIaCはまだ早かったのかもしれない
AWS Startup Meetup #13 LT 登壇資料です。 Infrastructure as Code（IaC）を導入したものの、IaC化した恩恵が思っていたより少なく、IaCで基盤を統一していく方針を転換していった話をご紹介します。
エンジニア一人しかいないとか言わないでほしいって言われた
そこそこの規模の業務用webシステムを一人で開発して運用してるんだけど、 問い合わせ対応とか要望対応が一人でやるには多すぎてさばききれないので （当システムは一人で開発運用しているのでお問い合わせはできる限りメールでお願いします、電話はクリティカルな用件だけにしてください） ってことを周知しようとしたら会社上層部からストップがかかった。 そんな事を言ったらシステムの信頼性を損なう 開発者が少ないのがわかったら足元を見られる バックにたくさんいるように見えたほうが印象いい という理由らしい。 そういうもん？ （追記） ブックマークがたくさんついてびびった。 ってことは、いろんな会社でこういうの結構あるんだね。 「これ書いたの君でしょ」って言われて困惑する人があっちこっちにいたら申し訳ないわ。。
金融の基幹システムを1年半かけて.NET 6に移行した話
はじめに 本稿は「.NET 6移行祭り！ C# Tokyo」イベントで発表した「金融の基幹システムを1年半かけて .NET 6に移行した話」の内容を文書化したものです。 [2022.08.28追記] さて、はじめにおことわりを。 おもったより大きな反響があって、想定より多く読まれており、とくに正しく伝えられていない箇所があると思い、少し補足を入れました。 ここで基幹システムといっていますが、金融の勘定系システムという意味ではありません。 基幹システムというとCore Systemという意味（これは勘定システムでしょうね）と、Mission Critical Systemの2つがあると思います。 本稿の対象は後者で、システムのお客様が、Mission Critical Systemと判断されて基幹システムとして扱われています。 金融の勘定系とは規模や複雑性、クリティカルな度合も異なりますが、
【懺悔】稼働中の本番DBで殆どのテーブルをtruncateしてしまった話 - Qiita
これは8年ほど前のある日のことです。 本番環境のテーブルを淡々とtruncateし続けたことがあります。 リリース前などではなく、稼働中のサービスでした。 思い出せる限り、私のエンジニア歴において最大の「やらかし」です。 「そんなミスありえないだろ…」「どんだけ迂闊なんだよ」という感想を持たれる方もいらっしゃるかと思います。 むしろ、それが正常だと思います。しかし、当時の私はやってしまった。 ただ、それでエンジニアをやめるようなこともなく、現在では人を指導する機会も増えました。 どうしたらそんな事が起きるのか？ その後、どのような対応が行われたのか？ 教訓はなにか？ この機に記させていただきたいと思います。 量産現場の社二病社員 当時働いていた職場では、「同じような機能を持ったスマートフォンアプリ」を量産する部署がありました。 私は、そこに配属されました。 当時、新卒２年目。社二病真っ只中
接続が途切れないストリーミングサーバの無停止アップデートを実装してみました - Mirrativ Tech Blog
こんにちは ハタです。 最近 SO_REUSEADDR / SO_REUSEPORT を使ったストリーミング配信サーバの無停止アップデート(Hot Deploy)を実装してみたので紹介したいなと思います ことの経緯 HTTPサーバによる Hot Deploy の仕組み ストリーミング配信サーバへの応用 SO_REUSEADDR/SO_REUSEPORT を使った実装例 Hot Deploy の組み込み Hot Deploy 実装時に気をつけたこと その後 We are hiring! ことの経緯 ミラティブでは以前から何度か紹介したとおり自前の配信基盤設備を持っています。 配信基盤のミドルウェアも内製であり、機能追加やライブラリの更新などがあるたびにミドルウェアのバージョンアップ作業(メンテナンス)も自社で実施しています ストリーミング配信サーバといっても、何か特別な事はなく一般的なHTT
みずほFG 坂井社長辞任へ 相次ぐシステム障害で責任明確化 | NHKニュース
システム障害が相次いでいるみずほフィナンシャルグループに対して、金融庁は改めて業務改善命令を出す方向で最終的な調整をしています。こうした事態を重く見て、みずほグループと、傘下の銀行のトップが経営責任を明確にするため辞任する方向となりました。 関係者によりますと、みずほフィナンシャルグループの坂井辰史社長は、一連のシステム障害の経営責任を明確にするため、再発防止の態勢が整った段階で辞任する意向を固めました。 また、いったんは辞任に向けて調整が進んでいたものの、再発防止策を徹底するため職にとどまっていた傘下のみずほ銀行の藤原弘治頭取も辞任する方向です。 みずほ銀行では、ことし合わせて8回のシステム障害が発生していて、9月には金融庁が再発防止に重点を置いた業務改善命令を出しています。 その後も検査を続けた結果、関係者によりますと、金融庁は管理を含めたみずほの企業統治の在り方に問題があるという見方
【独自】みずほ、新システム導入後に要員６割減らす…トラブル遠因になった可能性（読売新聞オンライン） - Yahoo!ニュース
システム障害を相次ぎ起こしたみずほフィナンシャルグループ（ＦＧ）が、新しい中枢システムを全面導入した後に担当の社員数を４割に減らしていたことが３０日、わかった。運用や保守・管理に関するノウハウが十分に引き継がれずトラブルの遠因になった可能性もあるとみて、金融庁はみずほ側に原因究明を求めている。 【写真】１円玉を５００枚持ち込んでも預金額は「０円」…手数料の仕組み ２０１９年に導入された中枢システム「ＭＩＮＯＲＩ（みのり）」の運用には、２１年３月末時点でみずほ銀行やみずほリサーチ＆テクノロジーズなどグループ会社で計４９０人が関わっている。全面稼働に向けた作業が本格化していた１８年３月時点の約１１４０人に比べて６割近く少ない。開発担当者らがグループ外向けの業務に配置転換されたとみられる。 みのりは、預金や融資、決済といったサービスごとにシステムを構築する先進的な仕組みで、他の大手行のシステムよ
勘定系システムは塩漬けにすべきか、みずほ銀行・静岡銀行の大規模障害で揺らぐ選択
勘定系システムの刷新を巡り、銀行間で明暗が分かれている。全面刷新に踏み切ったみずほ銀行などで大規模システム障害が起きた一方、アプリケーションの刷新は一部にとどめ、システム基盤の更改を進めた銀行で目立ったトラブルは起きていない。移行コストやリスクを抑えるため「勘定系システムは塩漬けでいい」という声も強まるなか、その選択肢は果たして持続可能なのか。 2021年に入り、銀行で大規模なシステム障害が2件起きた。1つがみずほ銀行だ。2月28日、定期性預金システムのトラブルがATMに波及し、4000台以上のATMが稼働を一時停止した。ATMがキャッシュカードや通帳を取り込み、店舗などで数時間待たされた顧客も出た。しかも、それから2週間あまりで立て続けに別の3件ものシステム障害を起こし、金融庁は業務改善命令を出す方向で調整している。 もう1つが静岡銀行だ。1月4日に他金融機関から同行宛ての振り込みの一部
grepを忘れただけなのに - Qiita
去年も『本番環境でやらかしちゃった人のアドベントカレンダー』は盛り上がりましたね。 知見が多く、関心しながら拝見しています。 人は必ず何かしらミスを起こすもの。 明日は我が身と思いながら、業務をこなす日々です。 そんな私も業界に入って1年目(前々職)に、本番環境の洗礼にあったことがございます。 当時は苦々しい思いをしましたが、その経験を供養するためにもここに残そうと思います。 発生当時の状況 事件当時、私はサーバのリプレイス案件にアサインしていました。 その業務の中で上司に日常的に運用されているスクリプトの調査を依頼されました。 私はまだ経験が浅かったため理解が合っているかは怪しいですが、関わっていたシステムは設計の段階で大分やっつけだったらしく、 格納場所が間違っているスクリプトやログが散見されました。 リプレイスを切っ掛けに整理をする予定だったと記憶しています。 入ったばかりのペーペー
はてなブログのキャッシュ周りをきちんと改善したら、アプリケーションサーバの台数を半分にできた話 - Hatena Developer Blog
はてなブログでSREをやっているid:cohalzです。 2019年12月頃からid:utgwkkやid:onkとともに、はてなブログにおけるキャッシュ周りの改善を行いました。その結果、次のような成果が得られました。 ブログ記事のキャッシュヒット率が、1日平均で8％から58％に向上 アプリケーションサーバの台数を、以前の半数以下に削減 DBに届くリクエスト数が、以前の3分の2まで減少 レスポンスタイムの平均が、以前の8割まで減少 この記事では、実際にどういった改善を行ったのか、その際に気をつけたことや大変だったことを紹介します。 はてなブログがVarnishを導入した経緯と課題 開発合宿をきっかけに問題が明らかになる 進め方をまず考える ホストのメモリをできるだけたくさん利用する メモリを積んだホストでなぜかレイテンシが悪化 キャッシュが分散しないようVaryヘッダを使う デバイス情報を適
物理サーバーを稼働させたまま引っ越しさせた意外な方法がネットで話題に
ウェブサービスが障害などで利用できないダウンタイムは、できるだけ少ない方がサービスを提供する側にとってもされる側にとっても望ましいもの。しかし、物理的なサーバーの移動といった作業は、電源を切ってダウンタイムを生じさせなければ困難にも思えます。そんなサーバーの物理的な移動を「ダウンタイムゼロ」で達成したという記事が海外掲示板のRedditに投稿され、話題を呼んでいます。 [Rant... sorta] Physically moved a server today... : sysadmin https://www.reddit.com/r/sysadmin/comments/i3xbjb/rant_sorta_physically_moved_a_server_today/ [FAQ][Rant... sorta] Physically moved a server today... :
デプロイ今昔 - Hatena Developer Blog
こんにちは。はてなのアプリケーションエンジニアの id:onk です。 最近、若手エンジニアを中心に、いろいろな技術を見つめ直すワーキンググループをやっています。今回は、その中から「デプロイ」の会で発表されたことをまとめました（なお、私は会のとりまとめをやっている非若手です）。 デプロイのライフサイクルの違い Infrastructure Platformでのデプロイ Application Runtime Platformでのデプロイ Applicationsのデプロイ デプロイ方式はどのように変化してきたか In place から Blue/Green へ Immutable Infrastructure という考え方 オートスケールへの対応 push 型デプロイと pull 型デプロイ コンテナによるデプロイの現況 コントロールプレーンによって何が変わったか ECS におけるデプロイ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
システム会社の一台のWebサーバー（Nginx）でのSSL証明書の更新作業の見積もりが20万円でした。ファイルをアップロードして再起動するだけですよね？ぼったくりだと思いますか？
【Linux】インフラエンジニアの僕が「hostname」コマンドを使わない理由とは？ - Qiita
cakes（ケイクス）
垂直スケールの果ての db.r4.16xlarge で得た教訓 / What happened on vertically scaled 16xlarge DB
