「システム運用アンチパターン - Forkwell Library #4」でお話しした際の資料となります。 https://forkwell.connpass.com/event/256481/ 動画はこちら。 https://youtu.be/hQAeMgXsZWc
「システム運用アンチパターン - Forkwell Library #4」でお話しした際の資料となります。 https://forkwell.connpass.com/event/256481/ 動画はこちら。 https://youtu.be/hQAeMgXsZWc
2022/06/13に「ニコニコ生放送 WebフロントエンドのKubernetes移行ハンドブック 2022」を公開しました。本発表ではハンドブックの内容とともに、WebフロントエンドにおけるKubernetesへの移行と運用がどのようなものか紹介します。 Playground
LINEの大規模なインフラを支えるインフラエンジニアが所属しているチームの役割や実際の仕事内容について、普段の働き方や現在の課題、取り組みなどを事例を交えてお話しする「LINE インフラエンジニア採用説明会」。ここでシステムデベロップメントチーム マネージャーの小笹氏が登壇。チームの担当業務について紹介します。 システムデベロップメントチームの業務内容 小笹哲哉氏(以下、小笹):システムデベロップメントチームの小笹です。よろしくお願いします。システムデベロップメントチームでは、システム室で行っているサーバーの管理や運用の業務に関連した、自動化や効率化の開発を行っています。 (スライドを示して)具体的には、ここに記載されているようなインフラ資産構成管理システムの開発・運用や、サーバーアクセス権限の管理システムの開発・運用。あと、低使用率サーバー検知、サーバーコストの管理システムの開発、サーバ
発表資料について 当時の発表資料とNuCon Mini 2022 Springで登壇した際の動画のリンクを埋め込んでおきますので、もしよろしければ御覧ください。 発表資料 「チームでサービスの運用をうまく支えていくための取り組み ~SREと共に~」 ちなみにこちらの動画では発表前にジョジョネタを盛り込んでいます。もしジョジョが好きな方がいましたら何部のセリフが使われているか当ててみてください。答えは当記事の最後にあります。 過去のGit Teamの体制と課題 Git Team誕生前 BacklogのSRE課にBacklogのGit機能の開発するメンバー1名を包含していました。メンバーはアプリケーションの開発・保守をメインで担当し、BacklogのGit機能に関連するサーバーの保守(kernel updateなど)はWebOperationが担当するという作業分担をしていました。 WebOp
MySQLの運用をコードで定義し大幅に自動化する「MySQL Operator for Kubernetes」がオープンソースで公開[PR] Kubernetesのようなコンテナ環境では、MySQLデータベースのようなステートフルで高い安定性が求められるソフトウェアを運用することは難しいと、以前は考えられていました。 しかし現在ではステートフルセットのような機能もKubernetesは搭載し、実装も安定してきていることから、ステートフルなアプリケーションをKubernetesで実行できる状況が十分に揃ってきました。 それだけではありません。Kubernetesには運用自動化を支える「Operator」と呼ばれる拡張機能が登場しました。これを用いると、Kubernetes上でさまざまなアプリケーションでの運用作業の多くが人手を介することなく自動的に行えるようになります。 そしてこのOpera
LAPRAS株式会社でSREをしていますyktakaha4と申します 🐧 私は 2021 年の 1 月に LAPRAS に入社 したのですが、 入社以来ほそぼそとやってきた、ドキュメンテーションに関する取り組みについて一年ほど運用し一区切りがついたので、その話をしたいと思います✍ ことのおこり 現在弊社には正社員・業務委託あわせて 18 名程度のエンジニアが在籍 していますが、 私が入社した頃はエンジニアが7名程度、かつ全体の人数に対して在任歴の長い人が多かったこともあり、 開発者が参照するドキュメント管理について、比較的牧歌的な運用がなされていました 🐑 具体的には、開発環境の構築方法が古い手順のまま放置されていたり、オンボーディングに使うドキュメントが口伝されていたりと、 ドキュメント自体は存在するものの、それらが 古くなっていたり一覧化が不十分であることが検知できず、時間経過に伴
こんにちは。中山(id:yoichi22) です Software Designに連載させていただいております「Pythonモダン化計画」では、モノタロウの社内事例から読者の皆様のお役に立ちそうな取り組みを紹介させていただいています。のですが、社内でも隣のチームがやってた取り組みを記事で初めて知ることもあって、私も読者として楽しませてもらっています。隣の執筆者さんありがとうございます。 今回は、運用にまつわる監視とログの話題です。本記事の初出は、Software Design2022年1月号「Pythonモダン化計画(第6回)」になります。過去の連載記事は以下を参照ください。 第1回 Software Design連載 2021年8月号 Python製のレガシー&大規模システムをどうリファクタリングするか 第2回 Software Design連載 2021年9月号 「テストが無い」からの
AWS環境をセキュアにセットアップする方法と、その運用方法を詳細に紹介します。秘伝のタレである具体的な設定も書いてます。みんな真似していいよ! こんにちは、臼田です。 みなさん、安全にAWS使えていますか?(挨拶 今日は全てのAWSユーザーが安全にAWSを活用し、セキュアに運用できるようにナレッジを大量にダンプしたいと思います。 弊社サービスに関連させて書く部分もありますが、基本的にどのようなAWS環境でも適用できると思います。 ちょっと長い背景 クラスメソッドでは長いこと様々なAWSを利用するお客様を支援しています。私は特にセキュリティ周りについて支援させていただくことが多く、最近はAWSのセキュリティサービスが充実していることから、これらの初期導入や運用設計、あるいはインシデント対応やその後の組織としてのセキュリティ体制づくりなどいろんな関わり方をしてきました。 どのようにセキュリティ
システムの保守運用体制に大きな問題があった――。みずほ銀行の一連のシステム障害に関して、そんな報道に接したとき、以前に大手銀行のIT関係者から聞いた話を思い出した。 「システムの保守運用の人的基盤が瓦解しつつある。ITベンダーの担当チームから優秀な技術者が散逸しつつあるのだ。過去に何度も料金を値切ったことで、優秀な人材をキープしてくれなくなった。新しく来る人たちを見ると能力の差は歴然だ」 この人は「もし大規模なシステム障害が起これば、適切に対処できるだろうか」と心配していた。幸い、この銀行はそのような事態に立ち至っていないが、みずほ銀行ではその懸念が現実のものとなった。コスト削減のために担当者を大幅に減らしたことなどで保守運用体制が脆弱になってしまったことが、システム障害の原因の1つとして取り沙汰されている。 ただし、システム開発が完遂し運用フェーズに入れば、担当者を「大幅に」減らすのは当
Author: Dylan Lau (@aidiruu), Platform DX Team Zero Touch Production (ZTP) is a concept where all changes made to production are done by automation, safe proxies or audited break-glass systems. There are many kinds of production outages that stem from human error, such as: Configuration errors Script errors Running commands in the wrong environment ZTP can mitigate the risk of outages from these e
今回はGitHubの話。 基本的な使い方は入門書がいくらでも出ているので今更私が解説するまでもないけど、ブランチ運用については腑に落ちるまで少し苦労したので今回は自分流のブランチ運用をメモとして残しておこうと思う。 ガチの開発勢から色々と文句を言わるかもしれないけど、趣味開発なのでご容赦願いたい。 thomの2ブランチ開発フロー 私は次の表の1~8のような流れで開発を進めている。 このブログの読者はExcelマクロ開発者が多いのでバージョン管理システムを使わないExcel開発を例えとして挙げてみた。対比させるとGitでやっている作業が何をしているのか少しは分かりやすいかなと思う。 本来は2~4を繰り返してこまめにdevブランチを更新しつつ、ある程度キリの良いところで充分にテストをしたうえでmasterへ取り込むんだけど、なんせ一人で開発していてユーザーも大抵自分ひとりというケースが多いので
この記事は GMOアドマーケティング Advent Calendar 2021 19日目の記事です。 はじめに こんにちは、GMOアドマーケティングのM.H(@masaseat)です。 自分はGMOアドマーケティングでアドネットワーク「AkaNe」とDSP「ReeMo」のProduct Managerを担当しています。 業務において広告配信結果の分析や、売上や性能のボトルネックをGoogleのデータウェアハウス「Google BigQuery」を用いて分析することが多いのですが、今回はその解析結果をプロダクトマネジメント業務や、広告運用メンバーの業務改善に活かしてみた方法をご紹介します。 分析環境について GMOアドマーケティングでは、広告配信結果のほぼ全てのログがGoogleのデータウェアハウス「Google BigQuery」に収納されています。 GMOアドマーケティングではエンジニア
こんにちは。エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiyでフロントエンドエンジニアをしているkodai(@r34b26)です。 色んなアドベントカレンダーをみながら、もう2021年が終わるのか…という実感が湧いてきました。 今回は、約2ヶ月前から開発チームで取り入れた「10min勉強会」について、その運用と改善の道のりを振り返ってみたいと思います。 勉強会がなかなか続かなかったり、チーム間のコラボレーションを促したい方にかなりオススメなので、よければご参考ください! 1. 10min勉強会を導入した背景 2. 運用のはじまり 3. つまずいたポイントと改善プロセス 3-1. 発表用の資料をつくらず、書記を立てる 3-2. ネタぎれ防止とkaizenをセットにする 4. 10min勉強会を運用してみての変化 5. さいごに 1. 10min勉強会を導入した背景 元
この記事は JPOUG Advent Calendar 2021 - Adventar 17日目の記事です。 昨日はShinodaさんの「Oracle Database から PostgreSQL への接続を試す - Qiita」でしたね。 いやーOracle Database Gateway for ODBC全然使ったことがなかったので、これはぜひやってみよ…あれ、RDSでできるの?明日AWSサポートに早速連絡してみよう… 最近ブログを書く頻度がアドベントカレンダー以外書く頻度がない感じになってきております…コレハ、マズイ、ゾ!!笑 さて弱気な内容はおいておいて…ここ最近、ろくに活動もできなかったのはこれをやっていたからなのです。 そうよくある、(꜆꜄•ω•)꜆꜄꜆オンプレOracleからRDSに移行した話。 今更感あるのですが、私と同じミスを減らすきっかけになれば。と思い、書いてみます
SREチームの安達(@adachin0817)です。今回WordPressサーバーであるEC2からECS/Fargateに移行しましたが、紆余曲折を得て、苦労したところ、技術的な部分、最終的には複数のリポジトリを一つにまとめたことなどを紹介したいと思います。まずはプロジェクトとサーバーの構成から説明していきましょう。 ランサーズのWordPressとECS時代のサーバー構成 https://engineer.blog.lancers.jp https://info.lancers.jp https://l-ap.jp https://connect.lohai.jp https://lohai.jp https://tips.lancers.jp https://www.lancers.co.jp https://www.lancers.jp/assistant/cases https:/
インフラエンジニア向けの書籍を取り上げ、著者と出会い、楽しく本を知り、仲間を作る場所である「インフラエンジニアBooks」。ここで、『運用改善の教科書』の著者である近藤氏が登壇。続いて、ITIL4の登場に伴う運用の考え方の変化と、昨今の運用に求められていることを紹介します。前回はこちらから。 2019年頃に起きた運用の変化 近藤誠司氏(以下、近藤):みなさん運用をやっている方が多いということで、ご存知のITIL(Information Technology Infrastructure Library)のv3、シラバス2011をベースにしたものを貼っています。いろいろとプロセスや機能などがあって、分類がありました。 シラバス2011、ITIL v3の時点では、基本的にはサービスストラテジが戦略を練る、サービスデザインは設計するというところです。トランジションは、設計したものを作って移行する
TL; DR Goで秘匿値をログに出力しないようにする zlog というロガーを作りました。 以下、経緯や使い方の説明です。 背景:サーバーサイドにおけるロギングと秘匿値の問題 Webサービスを含む多くのサーバーサイドのサービスでは、サービスの挙動に関するログを出力・記録しておくのが一般的です。継続的にログを出力しておくことで、トラブルシューティングやデバッグ、セキュリティインシデントの対応や監査、性能改善の手がかりなどに活用することができます。ログに含まれる情報が多いほど問題を解決するための手がかりが増えるため、(限度はあるものの)なるべく多くの情報を掲載する、あるいは設定によって情報量を増やせるようにしておくと便利です。 しかし一方で、サーバーサイドで出力するのは望ましくない情報もあります。 認証に利用される情報:パスワード、APIトークン、セッショントークンなど、それを使うことで別の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く