SRE はサービス品質に影響しない程度の異常をどう扱うべきか？ - 無印吉澤
今回の記事は、最近考えていたことのメモです。 ここ最近いろいろ考えていたのですが行き詰まってきたので、とりあえず課題意識を説明する文章だけ書いてみました。結論はまだありません。 障害と異常の定義 話の前に、障害（failure）および異常（anomaly）という単語を定義しておきます。人によって定義は違うと思いますが、自分が文章を書くときは以下のように区別しています。 障害：サービスの停止や、サービス品質の深刻な劣化を引き起こすようなインシデント 異常：サービスに対する深刻な問題は引き起こさないが、通常は起こらないはずのインシデント この定義をもう少し詳しく説明するために、例として、ロードバランサと、その背後に5台のアプリケーションサーバがあるシステムを考えます。 これらのサーバが5台ともダウンしたり、半数を超える3台がダウンして応答時間が極端に長くなった（例えば10秒以上になった）場合は
Wiki のページ、[[タイトル]] から作るか、いきなり作るか？ - 無印吉澤
最近、職場で Wiki について話していて、Wiki のページの作り方は2通りあるよね、って話になりました。 ページ本文のなかに [[タイトル]] と書いて保存し、あとからそのリンクを踏んで「タイトル」ページの作成画面を表示する いきなりページの新規作成画面を開いて、タイトルを記入する 僕はだいたい1番で作る方なんですが、毎回2番で作る、という人もいました。 そんなことがあって「僕の Wiki の使い方は普通じゃなかったのかな？」と思って調べてみたら、最近の Wiki の一部（Qiita:Team や esa.io）は 1番のようなページの作り方ができない んですね。 そうなのか！これは面白い！と思って、Wiki の歴史を遡って色々調べてみました。今回はそんなネタです。 Wiki ソフトウェアそれぞれのリンク記法 まず、Wiki の機能を持つソフトウェア（以下、Wiki ソフトウェア）につ
![Wiki のページ、[[タイトル]] から作るか、いきなり作るか？ - 無印吉澤](https://cdn-ak-scissors.b.st-hatena.com/image/square/3bca3eacc6de7dda4a41c6a567ab4d088b1e345a/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fm%2Fmuziyoshiz%2F20170827%2F20170827200124.png)
GNU social (OStatus) 自体の仕様に関する情報源まとめ - 無印吉澤
（上のロゴは、何故か スペイン語版の Wikipedia にだけあった。本当に公式のロゴ？） はじめに Mastodon 大人気ですね。 僕もとりあえず mstdn.jp と pawoo.net にアカウントを取ってお互いにフォローし、どれくらいの時間差でトゥートが伝達されるのか観察したり、GitHub に公開されているソースコードを少し読んだりしました。 「Mastodon は分散型だ」とか「GNU social と互換性がある」という話を聞いて、一体どんなプロトコルなんだろう……と気になって少し調べたのですが、GNU Social 自体がかなり古いものらしく、ドキュメントを探すのにも苦労しました。 そこで、自分で探した範囲で、原典に近いと思われるドキュメントのリンク集を作っておきます。新しい情報が見つかったら、随時更新します。 プロトコル同士の関係 以下のドキュメントに書かれている、O
信用できる社内 Wiki をつくるために守ってほしい、たったひとつのルール - 無印吉澤
このページについて この記事は、以前書いた「社内Wikiに情報を書くときに守ってほしい、たったひとつのルール」の続編です。前回は、個々のページをどう書くべきかという話をしましたが、今回は社内 Wiki 全体を信用できるものにする方法について考えます。 muziyoshiz.hatenablog.com 想定する環境 この記事は、ソフトウェア開発プロジェクトに関する Wiki が社内にあって、そこに各人がドキュメント（仕様書や手順書など）を書けるようになっている環境を想定しています。 私自身、ソフトウェア開発のときしか Wiki を使わないので、具体例もそのような環境に寄っています。ただ、ある程度は社内 Wiki 全般に通じる話かと思います。 ルール：「更新され続ける」ページと「更新されない」ページをはっきり分ける ここ1年ほど社内プロジェクトをいくつか渡り歩いていたのですが、個人的には、こ
Ansible の --extra-vars 引数を安全に使うためのラッパーを書いてみた - 無印吉澤
最近は、仕事でも趣味でも、サーバ構築を自動化したいときは Ansible を使ってます。 アプリケーションのデプロイには Capistrano も使うんですが、つい最近 Ansistrano という便利な Ansible role の使い方を覚えてしまったので、そこも Ansible で済むようになりました。 recruit.gmo.jp ansible-playbook の --extra-vars 引数 ところで、Ansible の playbook を書いていると、「普段の動作は決まっているけど、ごくまれに違う動作をさせたい」ことがたまにありませんか？ そういうとき、僕は ansible-playbook の --extra-vars 引数（-e 引数）を良く使います。 例えば、自作のアプリケーションをデプロイするための playbook で、「普段は master ブランチをデプロ
無印吉澤
本日12/24発売のWEB+DB PRESS Vol.132に、私が執筆した「コンテナ化実践ガイド」が掲載されました！ 今までいろいろ文章を書いてきましたが、実は、書店に並ぶ雑誌に記事を書いたのは初めてです。ドキドキしながら発売日を待ってました。 gihyo.jp ちなみに、電子版がほしい方はGihyo Digital PublishingのEPUB/PDFセットがおすすめです。 gihyo.jp 想定する読者は？ 歴史の長いシステムで、モノリシックなアプリケーションを開発・運用している方に向けて、コンテナ化を進めるためのステップを具体的に解説したガイドです。 ここまで具体的に（悪く言えば泥臭いことを）説明している資料は、少なくとも僕は見たことがないので、これからコンテナ化に着手する人には必ず役立つと思います。「うちのシステムをコンテナに乗せて、本当に動くのか……？」と悩んでいる方に是非読
Mastering Bitcoin（日本語訳 PDF）を読んで解決した疑問点、しなかった疑問点 - 無印吉澤
「ブロックチェーン」という単語をニュースでよく見かけるようになってきたので、そろそろ常識として抑えておこうと思い、Bitcoin の名著として評判の高い "Mastering Bitcoin" を読みました。 Mastering Bitcoin: Unlocking Digital Cryptocurrencies 作者: Andreas M. Antonopoulos出版社/メーカー: O'Reilly Media発売日: 2014/12/03メディア: Kindle版この商品を含むブログを見る 日本語版はまだ発売されていませんが、有志による日本語訳が以下のサイトで公開されていたので、今回はこちらを読みました。レイアウトが少し崩れているところもありますが、全体的に読みやすい訳でした。 日本語訳 PDF の公開サイト： Translations of Mastering Bitcoin |
社内Wikiに情報を書くときに守ってほしい、たったひとつのルール - 無印吉澤
このページについて これは、社内 Wiki に情報を書くときに、私が個人的に守っていて、チームメンバにもできるだけ守ってほしいルールの紹介記事です。このルールを実際に運用するためのコツについても、基本ルールの派生という形で紹介します。 想定する環境 この記事は、社内に Wiki があって、フォーマットが決まったドキュメント（仕様書や手順書など）とは別に、各人がメモを自由に書いて共有できるような環境を想定しています。 Wiki の種類は問いません。PukiWiki、MediaWiki、Confluence、Esa、Redmine などのプロジェクト管理ツール付属の Wiki などなど……何でもいいです。Word 文書などにも適用できなくはないですが、文書を気軽に分けるのが難しい場面には、あまり向かないかと思います。 ルール：「このページについて」という欄をページの先頭に用意し、そのページの概
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
