はじめに こんにちは植木和樹@上越妙高オフィスです。本日は私がここ10年くらい意識している運用手順書を書くときのポイントについてまとめてみました。 対象読者 開発・構築したシステムを別の人に引き継ぐ予定のある人 他の人が作ったシステムを引き継ぐ担当の人 半年後の自分でも分かる手順書の書き方に困っている人 (この記事を読むのにかかる時間の目安:5分) 1. ドキュメントの冒頭に書くこと まず個々の詳細手順の前に、ドキュメント自体について記載してもらいたいことです。 1.1. ドキュメントに書かれていることを3行で書く ドキュメントの最初には、このドキュメントに何が書かれているのかを100文字くらいで書いておくと良いでしょう。 システムが増えれば増えるほど手順書も増えていくものです。見つけたドキュメントに自分の期待するものが書かれているのか、冒頭数行でわかるようになっているとうれしいです。 1
負荷試験シリーズ、書きたいことはイッパイある気がするんだけど、技術の総括的な感じがエグくて、どうしてもまとまりがなくなってしまう…… ということで、気分転換にザックリお絵描きしました。これで少しはテーマを切り取って小綺麗に書いていきやすくなったはず。 負荷試験の流れ それがこれじゃ!いくらでも肉付け項目が出てくるだろうけど、1画面に収める内容としては最小限としてほどよくまとまったはずである。 だいたい分かってもらえると思うけど、一応軽く説明はしておきます。長くならないよう、一言二言ずつで! 環境 クライアント・リソース 負荷試験ツールを動かすためのサーバー(群)。EC2 や ECS Fargate などのスポットで起動して安く済ませる。使い捨て用途なので、環境一式を作ったり削除したりを、一手で簡単にできるようにしておくと吉。 負荷試験ツール 疑似ユーザートラフィックを発生させるためのツール
Merpay Tech Talk 〜事業成長を支えるArchitectチームの取り組み〜 を開催しました! #merpay_techtalk 2021年12月14日に、『Merpay Tech Talk 〜事業成長を支えるArchitectチームの取り組み〜』 を開催しました。 この記事はイベントレポートです。配信当日の内容を簡単に紹介します! 詳しくはYouTube上にある配信アーカイブ動画をご視聴ください。 イベント概要 今回のイベントでは、毎回各テーマに興味のあるエンジニアたちが集まり、技術的な知見を共有しあうことを目的とした勉強会です。 今回のテーマは、「事業成長を支えるArchitectチームの取り組み」です。 技術的なTopicも紹介しつつ、あわよくばメルペイのArchitectチームに興味を持ってもらいたいという回です。 想定対象者は以下のとおりです。 Backend Eng
残業も減らせる!? 上級エンジニアになるためのDesign Doc超入門:プロジェクト成功確率向上の近道とは?(3)(2/3 ページ) Design Docを書く いよいよ、Design Docを書いていきます。初めにやることは、システムに名前を付け、ドキュメントの冒頭の部分に署名し、そしてこのソフトウェアの目的やゴールを書くことです。 名前を付ける 不思議なことに、良い名前を付けると設計がはかどります。そのシステムにふさわしい名前を付けて、表紙に記載しましょう。 目的やゴールを書く 目的・ゴールの書き方の基本形は『このソフトウェアの目的は★★であり、◯◯を実現することがゴールである。』という定義文のスタイルです。何か誤解を生じる恐れがある場合は『なお、このソフトウェアには、××機能は含まない。』といった形で、除外されるものを明確にすることもあります。 目的・ゴールは、できるだけ明確に書い
How Google Works (日本経済新聞出版) 目次 目次 はじめに Design Docの要点メモ 参考資料 MyEnigma Supporters はじめに GoogleなどのIT企業がソフトウェアを開発する際には Design Docというドキュメントを利用しているそうです。 Design Docは「設計書」と訳されることが多いですが、 日本語の設計書とは少し意味合いが違うようです。 今回は、このDesing Docの要点を、 末尾の参考資料を元に勉強してみたので、 自分用のメモとしてまとめておきたいと思います。 Design Docの要点メモ Design Docは、 これから新しく開発しようとするソフトウェアの全体の設計や、 既存のコードのpatchやプルリクエスト(PR)のコード変更の 基本的な要点をまとめる文書です。 PRを作成する前に、Design Docを作成して
早いものでLINE株式会社に入社して3年が経ちました。今日から勤務4年目となり、業界としてはそれなりに長く働いている側に足を突っ込んできた自覚があります。仕事もエンジニアからマネージャーになり、役割も変わってきたところ。 現職でまだやりたいこともあるだけでなく、明確にバリューを出せていて組織からも評価されている現状、しばらく転職する予定はないのですが、一方で、私は常に他の選択肢がないかを探し続けています。 そして一緒に働く同僚やチームメンバーには語弊を恐れずに言えば「常に転職活動をしながら仕事をしてほしい」と思っています。 現職についてのエントリに興味がある人はそう多くないと思うので、3年目が終わった節目として、今日は市場を見て仕事をすることの重要性について書き記すことにしました。 自社に満足しているときほど、外部の働き方を知る必要がある 「あなたは今の仕事に満足していますか?」と聞かれた
はじめに アンドパッドの土方です。 最近エンジニア採用に携わっております。 今回はアンドパッドの開発組織について紹介したいと思います。 はじめに 開発組織のミッション テクノロジーを武器に社会変革にチャレンジする 開発組織が取り組んでいること 開発の進め方、チーム 技術顧問の参画 継続的アウトプット 開発における様々な改善活動を行っています エンジニア組織 プロダクト開発部門 品質管理/保証部門 テクニカルサポート部門 アプリケーション基盤部門 SRE/データ基盤部門 技術スタック 終わりに 開発組織のミッション テクノロジーを武器に社会変革にチャレンジする 私たちの開発しているANDPADは、少しだけ便利に、というよりも革新的に仕事環境が変わったというインパクトを与える可能性を持っています。 プロダクトの開発を通して業界の働き方に変革を起こす、テクノロジーを武器にチャレンジすることが開発
Amazon Web Services ブログ [AWS Black Belt Online Seminar] CON142 Docker 入門 資料公開 AWS Black Belt オンラインセミナー「CON142 Docker 入門」を公開します。 視聴は YouTube から、資料閲覧は SlideShare から可能です。 コンテナ技術は新しい技術ではなく、1980年台の Unix chroot を始まりとして複数のコンテナ技術が過去にも存在していました。過去のコンテナ技術は OS 仮想化領域に注力していましたが、Docker はアプリケーションをパッケージングしデリバリするところに注力し、スムーズな開発者エクスペリエンスを提供したことで新しいイノベーションを起こし市場の注目を集めました。本セッションでは、このようなコンテナの歴史背景の説明から始まり Docker のアーキテクチ
※この記事は2020年9月25日に公開されたものです。 資産形成の正解は人それぞれですが、一方で、多くの人が失敗してしまう考え方や、やり方があるようです。このシリーズでは、資産形成を始める人が陥りがちな失敗事例を取り上げ、やってはいけない行動をわかりやすく解説します。 お悩み できるだけ家計の負担を少なくして、住宅ローン返済はできるのか? 北川浩さん(仮名)会社員・30歳(既婚) 北川さんは現在、奥様と2歳の長女との3人暮らし。家族の将来を考えて、資産形成に取り組んでいました。そんなとき、新型コロナウイルス対策でテレワークが続き、現在の賃貸マンションでは公私の区別がつけづらくなったため、郊外に家を購入することを考え始めました。 自宅購入にあたり住宅ローンの利用を考えていますが、北川さんにとってローンを組むのは初めてのこと。ローンの見積もりをしてみたところ、返済期間を短くすればそれだけ毎月の
Amazon Web Services ブログ 初めてのPerformance Insights入門 テクニカルソリューションアーキテクトの笹川です。 本記事ではRDS MySQL使用時のPerformance Insightsの使い方についてご紹介させて頂きます。 Performance Insightsを聞いたことがあるけれど何ができるのか分からない、実際にどのように活用すれば良いのかイメージができないという方もいらっしゃるのではないでしょうか。今回は初めてのPerformance Insights入門と題してサンプルのクエリを実行しながらPerformance Insightsの使い方をご紹介していきます。 Performance InsightsとPerformance Schema Performance InsightsではDBの負荷状況がMySQLにログインすることなくAWS
負荷試験シリーズの実質初弾としては、ツールの選択について考えていきます。 基本的な基準を捉えつつ、私自身の要望を整理し、何に決定していったのか、という流れで参ります。 選定基準 前記事にも記載しましたが、このページは非常に参考になるので、まずは雰囲気だけでもサラリと読んでみるとよいです。 Open source load testing tool review 2020 Open Source Load Testing Tools: Which One Should You Use? | BlazeMeter ツールは必要? そもそも負荷試験ツールを使う必要があるのか、についてからですが、「必要はあります」で言い切って良いと思います。 選択しない場合、自身で何かしらコーディングすることになるわけですが、実装内容によってはできなくもない話とはいえ、より複雑になるほどオレオレ度合いが高まってコ
Contents はじめに commit.template でコミットメッセージテンプレートを設定する おわりに 愛用品 はじめに Git のコミットメッセージテンプレートを設定する方法について調べたことをまとめました. テンプレ化が好きなので調べて面白かったです. それでは参りましょう. 参考: ProGit 8.1 Git のカスタマイズ - Git の設定 git config – git の設定ファイルの優先度を深く知る | typememo.jp commit.template でコミットメッセージテンプレートを設定する 早速ですが,コミットメッセージテンプレートの設定コマンドはこちらです. $ git config [--system | --global | --local] commit.template /path/to/.gitmessage.txt 事前に .gitm
Conventional Commits 人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様 Conventional Commits 1.0.0 概要 Conventional Commits の仕様はコミットメッセージのための軽量の規約です。 明示的なコミット履歴を作成するための簡単なルールを提供します。この規則に従うことで自動化ツールの導入を簡単にします。 コミットメッセージで機能追加・修正・破壊的変更などを説明することで、この規約は SemVer と協調動作します。 コミットメッセージは次のような形にする必要があります: 原文: <type>[optional scope]: <description> [optional body] [optional footer(s)] 訳: <型>[任意 スコープ]: <タイトル> [任意 本文] [任意 フッター] あな
AWS による docker コンテナのオーケストレーションサービスである Amazon ECS / Fargate のヘルスチェックの挙動について調査する機会がありましたのでアウトプットしておきたいと思います。 前提として Fargate で ECS のサービスとして、ロードバランサーは Application Load Balancer(ALB)を利用して実行するケースで調査しました。網羅的ではない点、ご了承ください。 ECS におけるヘルスチェック さて、ECS でサービスを実行する上で、いわゆる「ヘルスチェック」は2種類あります。 Elastic Load Balancer(今回は ALB)に関連付けられる Target Group によるヘルスチェック タスク定義のコンテナに対して実行する docker によるヘルスチェック(参考 : docker ドキュメント, AWS ドキュ
シンジです。Slackに絵文字を登録する方法に、Google Chromeの拡張機能でBulk Emoji Uploaderを利用すると便利なのですが、登録したい絵文字の数が数百とか数千数万になると超大変です。そんなに手元に絵文字画像ないよって話ですが、デコモジという公開絵文字が3万近くあるので、これを登録してみます。 注意 いきなりSlackテナントに3万件近い絵文字が増えるとパニックになる人もいるかもしれません。画像選別しても良いと思います。SlackAPIを利用してアップロードするので、1画像ファイルを1つずつ丁寧に気持ちを込めてアップロードします。都合、17時間くらいかかります。 デコモジという努力の結晶 ここの画像を絵文字として登録します。ありがたやありがたや。 Custom icon collection for slack reaction. Contribute to de
はじめに CTOの川口 (id:dmnlk) です。 5月にオンラインmeetupをさせて頂きその中で「具体的な負荷対策に関しては開発ブログで!」と言っていた件ですが気づいたらもう9月になりかけていました。 コロナ禍においてネットショップ作成サービス「BASE」の利用者様が急増しました。 www.nikkei.com 5 月には 100 万ショップを超えるショップオーナー様にご利用していただいております。 今まで EC 事業を行っていなかった飲食店様や様々な業種の方が利用をはじめていただき、ショップオーナー様も購入者様共に短期の見通しでは想定をしていないアクセスが発生しました。 その途中でシステムとして対応しきれない面もあり、アクセス負荷によるサービスの不安定を招き皆様にはご不便や販売時間を変更していただくお願いなどをしてしまい大変申し訳ありませんでした。 現在では安定しておりますが、その
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く