いかに運用作業に手を抜くかという話 - pospomeのプログラミング日記
最近「いかに運用作業に手を抜くか」というのを考えているので、なんとなーくアウトプットしてみようと思う。 運用作業とは? 運用作業はゼロが理想だけど、そーもいかない 運用を頑張りすぎてしまうエンジニア pospomeはどうしているか? まとめ 運用作業とは? 自分が想定する "運用作業" というのは機能開発に関係ない作業全般である。 例えば以下の作業は "運用" にカテゴライズしていいと思う。 ソフトウェアのバージョンアップ ユニットテストの実装・保守 問い合わせ対応 リファクタリング 運用作業はゼロが理想だけど、そーもいかない 自分は運用作業がゼロになるのが理想だと思っている。 可能であれば、機能開発にすべての工数を投じて、自身が開発するプロダクトを進化させていきたい。 ただ、運用作業をゼロにするのは不可能である。 ソフトウェアのバージョンアップは定期的にしなければいけないし、リファクタリ
運用設計における設計項目の体系化 / 20240207-ssmjp-operation-design-items
ssmjp ssmonline #38 "第四回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/307397/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
僕が障害復旧対応時に考えていることを言語化してみる - Qiita
これまで数多くのシステム障害を復旧してきました。 障害は無いに越したことは無いですし、起こらないように最善を尽くすのが我々エンジニアの使命です。 しかし、どれだけ最善を尽くしても起こる時には起こります。 今回は、これまで数多くの障害を復旧させてきたエンジニアが、復旧作業時に何を考えているのかを改めて言語化してみたいと思います。 こういう情報ってそれぞれのエンジニアの頭の中にあってあまり共有されないので、意外に参考になるかなと思います。 障害復旧対応の醍醐味 表現が適切かは分かりませんが、僕はシステム障害を復旧させるのが大好きです。目の前に起こっている事象からヒントを集め、地道に原因を切り分けてクリティカルヒットを見つけたときは名探偵になった爽快感があります。 加えて、動いているものを常に動かし続ける日頃の保守運用とは異なり、動いてないマイナスの状況を0まで戻すということで、復旧成功した際に
ひとり情シスの味方！お手軽社内サーバ監視・リモートデスクトップ接続 | IIJ Engineers Blog
データセンター・エンジニアリング関連サービスの企画と開発を担当。もともとアプリ開発でスクラムマスターを経験しアジャイルに造詣が深く、世界のDX推進をインフラ設備から支えたいと考えている。 私の所属するチーム（基盤エンジニアリング本部基盤サービス部サービス開発課）では、DX edgeというエッジデータセンターソリューションを開発・運用しています。お客様の社内に設置したエッジデータセンターをIIJが遠隔で運用保守するマネージドサービスも提供しています。リモートから監視・運用するために、IIJ IoTサービスを活用した運用保守用のリモートアクセスする仕組みとゲートウェイ機器（リモートアクセスボックス）を開発しました。 先日、あるお客様から手軽に社内サーバへアクセスするためにこの仕組みが便利そうなので譲ってくださいとお願いされました。そこで、このリモートアクセスボックスを提供したところとても高評価
GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる
GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる GitHubが提供するGitHub.comは、世界最大のソースコード管理システムを始めとするソフトウェア開発者向け支援サービスを提供しています。 そのGitHub.comはRuby on Railsで構築されており、同社はつねにRubyとRuby on Railsをアップデートし続けていることを今年（2023年）4月に明らかにしています。 参考：GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている そして同社はこのGitHub.comを支える1200台以上のMySQL 5.7を、GitHub.comのサービスレベルを維持したまま1年以上かけてMySQL 8.0にアップグレードしたことをブログで明らかにしました。 Up
ヘルプデスク業務を楽にするためにSlackとGitHub Projectを同期するヘルプデスクツールを自作した - MNTSQ Techブログ
こんにちは。MNTSQの下村です。 コーポレートエンジニアとして、MNTSQ従業員の生産系向上施策等を実施していたりします。 ( Twitterもやっている のでフォローしてもらえると嬉しいです！ ) 本日は社員からの問い合わせ業務 いわゆる ヘルプデスク業務について効率化するためのツールを自作した 話を書いてみます。 この記事の要約 一人目コーポレートエンジニアとして参画したがヘルプデスク業務が非効率だったので効率化した。 質問に対して特定のemojiを押すとGitHub ProjectsのItemを作成するようにした。 SlackスレッドのコメントとGitHub ProjectsのItemを双方向同期するようにした。 Azure OpenAIも利用して効率化した。 きっかけ 2023年5月からMNTSQの一人目コーポレートエンジニアとして参画しています。 情報システムを色々と整備してい
社内ドキュメントはなぜ更新されないのか？情報の鮮度を最小限の運用負荷で維持する「イミュータブルドキュメントモデル」のススメ - KAKEHASHI Tech Blog
はじめに こんにちは。カケハシの各プロダクトを支えるプラットフォームシステムの開発チームでテックリードを担当しているkosui(@kosui_me)です。 プロダクト開発の世界では、明瞭な社内向けドキュメントを書くための方法が数多く提案されてきました。読者の中には、製品要求を明瞭にするためにPRD (Product Requirements Document、製品要求仕様書) を書き、プロジェクトの背景から全体の設計やその代案について明瞭にするためにDesign Docsを書き、アーキテクチャに関する意思決定の記録を明瞭にするためにADR(Architecture Decision Record) を書いてきた方も数多くいらっしゃると思います。 しかし、どんな素晴らしいドキュメントも、何故か更新されなくなります。新メンバーへのオンボーディングのためにインフラ構成図を検索したあなたが見つけた
障害対応プロセスを改善してきた話 - 10X Product Blog
障害プロセスを改善してきた話 こんにちは。Reliability & Securityチームに所属するSoftware Engineerの@sota1235です。 今回は10X内における障害対応プロセスの改善をご紹介します。 今が完成系ではなく道半ばではありますがこの半年 ~ 1年で大きく進化したので同じくらいのフェーズの会社で困ってる方がいたら参考にしてみてください！ ちなみに私ごとですが去年の5/26にこんな投稿をしてたのでやっと伏線を回収する形となります(※ ドヤ顔ではありません)。 目次 こんな感じで紹介していきます。 目次 障害対応プロセスの改善に踏み切った背景 課題1. 障害の報告フォーマットが統一されていない 課題2. 障害報のクオリティの差異が大きく後から振り返りが難しい 課題3. 障害対応者が特定の人に偏る 第一の改善 改善1. 障害報告書のフォーマット更新 改善2. S
人生を仕組み化していったら結婚できた件 - Amosapientiam
この記事は妻にレビューしてもらっています。 概要 この春結婚しました。 我々二人の生活は、多くの仕組み化・組織化を実行しているという点でかなり変である、ユニークだと思います。この記事では我々が導入している仕組み化を紹介していきたいと思います。 経緯 妻とは一年ほど前から人生をよりよく生きるためのアドバイスをし合う朋友・盟友的関係を築いていました。 お互いの人生には課題が山積しており、それを抜本的に改善する必要があったのです。 そのために我々は仕組みの力に頼ろうと、さまざまな人生の仕組み化を図りました。 改革は功を奏し、我々の抱えていた諸問題は対処可能になっていきました。 また、お互いの課題解決的なコミュニケーションが大いに促進され、相互理解が深まっていきました。 我々の協力関係が実り多いものであることを深く確信した我々は、お互いの人生に貢献したい、二人三脚でこの人生を楽しんでいきたい、一緒
AWS監視アラート 事始め - mazyu36の日記
はじめに 入門監視をはじめ一般的な監視に関するプラクティスは出回っているものの、AWSで具体的に何を監視するか？そのとっかかりについてはあまり出回っていないような気がします。 AWSの監視ってみんな何監視してるんすか…っていうぐらい実例あまり見つからないな。門外不出？— mazyu36 (@mazyu36) 2023年2月14日 どこまで監視するかは基本的にシステムの特性によると思います。一方でAWSのサービスごとにシステムによらずよく監視で使う項目というのもあるかと思います。 今回は過去の経験をもとに、最低限この辺りは監視することが多いかなというものをまとめてみます。全体像としては以下になります。 最低限これは監視しないとダメでしょ、とかこれは不要でしょ、などなどあるかと思います。そういうのがあればぜひコメントいただきたいです。 はじめに 「監視」について 前提 1-1. Webサービス
【AWS】ぼくのかんがえたさいきょうの運用・監視構成 - Qiita
AWSのインフラを運用・監視する上で使いやすいと思ったサービスを組み合わせて構成図を作成しました。それぞれのサービスの簡単な説明と類似サービスの紹介、また構成の詳細について説明していきます。 (開発で使用するようなサービスも紹介しますが、あくまでも運用・監視だけの構成です。) 各個人・企業によって環境は違うと思いますし、使いやすいと思うサービスは人それぞれだと思うので、これが正解という訳ではありませんが、参考にしてただければ幸いです。 参考になった教材を紹介した記事も作成しました。是非読んでみてください！ 【AWS】さいきょうの運用・監視構成を作成するのに参考になった書籍 インフラエンジニア1年生がプログラミングを勉強するのに使った教材 全体図 こちらがAWSにおける"ぼくのかんがえたさいきょうの"運用・監視構成です。複雑で分かりづらいかと思うので、詳細に説明していきます。最後まで読めばこ
「運用でカバー」を増やさないために カウシェが実践する「小さく出し、小さく失敗する」
「運用でカバー」を増やさないための対策 向井毅男氏（以下、向井）：というところで、運用でカバー（すること）はよくある話です。カウシェさんでも、やはり運用でカバー（すること）を前提に仕様を決められたアンチパターンがあったと聞いています。池松さんにそのあたりを紹介してもらってもよいですかね。 近藤優輝氏（以下、近藤）：池松さんが固まってしまったかもしれない。 向井：固まっちゃいましたね。まぁ、オンラインあるあるですね。 見ている方、なんでもけっこうです。気になること、些細なことでもけっこうなので、ぜひ質問とかコメントとかもらえればと。あっ、池松さん動きましたかね。たぶんミュートになっているので。 池松恭平氏（以下、池松）：すみません。聞こえていますか（笑）？ 向井：大丈夫です。じゃあ、あるあるパターンの、運用でカバーのアンチパターンをお願いします。 池松：わかりました。「運用でカバーできれば良
バッチ処理 プラクティス
バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か？」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。
Helpfeelならできるよ？情シス/バックオフィスのフルリモートワーク | 株式会社Helpfeel
株式会社Helpfeelに入社してまだ2か月目の、コーポレートIT担当のMです。 今回は私の入社エントリです。情シスとしてコロナ禍の転職活動でよく言われたこと、そしてそこから感じたこと、そしてHelpfeelという会社に入って思ったことなどをつらつらと書きなぐってみたいと思います。文才はありませんので、脈略無くなるのはあらかじめご了承ください。 ※情報システム部門やコーポレートITは企業によって呼び名が多岐にわたるため、この記事ではまとめて職務名を「情報システム部門」「情シス」、人のことを「メンバー」と記載させていただきます。 転職活動の中でうんざりしてしまったものさて… 情シスをしている私が、転職活動中にカジュアル面談や面接で「とある質問」をすると、8〜9割は次のように言われました。 「うちはコロナが落ち着いたら出勤です。」「情シスは、基本的にリモート勤務は無理ですねぇ。みな出勤していま
AWS未経験者なのに運用リーダー？ SCSK小出氏は「70個のドキュメントと26の業務」をどうやって引き継いだのか
企業でのクラウド活用は当たり前となった。ただ、導入のハードルが低いといわれるクラウドであっても「オンプレミスと異なる運用に戸惑っている」「今まさに勉強している」というインフラ運用担当者は多いだろう。 また、クラウドサービス自体は使ったことがあるという人でも、会社の方針で新しいクラウドを使うということは十分あり得る。そうなれば一から「クラウドの運用」を勉強し直す必要がある。 Cloud Operator Days Tokyo 2022のセッション「AWSを触ったことのない運用者が、AWS環境のインフラ運用巻取りを通じて、運用改善をできる様になるまでのお話」では、Amazon Web Services（AWS）での運用経験がないのに運用チームリーダーを任されることになったSCSKの小出泰介氏（ソリューション事業グループ マネジメントサービス第一事業本部 製造マネジメントサービス第二部 チームリ
障害報告書を書こう！ - Qiita
担当しているITサービスなどに何かしらのインシデントや障害が発生した時に、対処後のアクションとして報告書を提出して事象の内容を報告（レポート）する場合がある。 提出先は会社の偉い人だったりクライアントだったり。場合によってはユーザー向けに発表したり。事の顛末を報告して「今後同様のことを起こさないように努力します、ごめんなさい」をするのだ。どのように再発防止の努力するのかを書くものでもある。 主にクライアント向けのビジネス内容ではあるが、自分が使っているテンプレパターンを共有するので参考にしてもらえればと思う。1 全般的なポイント 心得のようなもの。次の点は留意してて欲しい。 淡々と冷静な説明をこころがける 当然のことながら事実は脚色しない。無駄な修飾も要らない。客観的な事実を簡潔に述べる。 例： ❌「一生懸命頑張って対応したが…」 ❌「寝ないで対応したが…」 ❌「本当の原因は…」 できるだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
情報処理システム高信頼化教訓のリンク集（ITサービス編） | アーカイブ | IPA 独立行政法人 情報処理推進機構
問い合わせ率が3年間で半分になった
非ITの事業会社にSREと言わずにSREを持ち込んだ
Engadget | Technology News & Reviews
