サービスレベル：設計と運用のプラクティス - 下町柚子黄昏記 by @yuzutas0
概要 サービスレベルをいかに設計し、いかに運用するか。自分なりの考えの整理です。 尋常ではない長さになりました。随時アップデートします。たぶん。 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) 作者: John Allspaw,Jesse Robbins,角征典出版社/メーカー: オライリージャパン発売日: 2011/05/14メディア: 大型本購入: 10人 クリック: 923回この商品を含むブログ (50件) を見る もくじ 概要 もくじ SLAとは何か 関係者が同じ目線を持つためのもの 火の一ヶ月間を経て…… SLAは契約ではなく、目標の合意に過ぎない SLA：設計のプラクティス サービスのレベルを設計する 機能観点でのレベル分け コア機能を定義する 非機能観点でのレベル分け オペレーションのレベルを設計する 対応速度のレベル分け 3
運用から見たシステムに関してのあれやこれや - 覚えたら書く
ITシステム(サービス, アプリケーション)の開発を行っていると、設計してコード書いてテストしてリリースするという流れになり、 このリリースというのがゴールという感覚に陥る場合があります。 実際は、システム(サービス)は運用が開始されてからがスタートだと言っていいと思います。 が、私含めた開発者というのは往々にして運用フェーズに対して意識がいきにくい気がします。 （DevOpsが広まった世の中ではそんなことないんですかね？私の感覚が古すぎ？） これまでの経験から、運用観点でシステムがどうあるべきか、開発者が何を意識しておくべきなのか を書きました。 （思いっきり個人的な見解なので、システムやサービスやビジネスモデルによって当てはまったり当てはまらなかったりだと思います） 実行環境 実環境とQA環境は一致していない 開発環境やQA(品質保証)環境が実際のサービスが動作する環境と(スペックやリ
Javaでユニットテストを書く時に気を付けたいこと - 覚えたら書く
Javaプログラムに対するユニットテスト(単体テスト)を書く際に気にしておきたいことを書いてみました。 以下、個人的な経験則と本で読んだ内容が混ざっています ユニットテスト作成時の原則 「このクラスはＸＸＸの理由でユニットテストが難しいんです！」と言いたくなったら ⇒ ユニットテストし易いように対象のクラスを作る（作り直す） 一般的にこのような設計の変更をした方が実運用にも適していたり、要件変更への対応が柔軟になったりする場合が多いです privateメソッドを強引にユニットテストしない リフレクションを使って出来なくはないが、基本的にやるべきではない。ユニットテストが内部の実装に依存しすぎる 呼び出し元のpublicメソッドのユニットテスト経由で処理を網羅すればよい どうしてもprivateメソッドのテストをしたいなら、そもそもprivateメソッドではなく別クラスのpublicメソッド
golangでAPIなど外部にアクセスするロジックのテストをする - $shibayu36->blog;
golangで、例えばGithubのAPIを叩くような、特定のAPIにアクセスするロジックを書いた時、何も考えずにテストを書くと、テストを実行する際にもそのまま外部のAPIにアクセスしてしまう。この場合、色んなパターンのテストを書きづらい、依存している外部サービスが落ちたらテストも一緒に落ちるなどの問題が起こる。 このような問題から、統合テストではなくユニットテストのときは手元のみで完結して、外部サービスに依存しない状況でテストを書きたくなることがある。そこで今回は外部にアクセスするロジックを、手元で完結させた状態でテストする方法を試したので、その方法について書いてみる。 テストしたいコード 例えば以下のようなコード。Githubの https://github.com/shibayu36/shibayu36 の最新のリリースタグを取得し、そのリリースタグ名を出力する。これはGithubの
Goのnet/httpとKeep-Alive - sambaiz-net
Keep-AliveするとTCPコネクションを使い回し、名前解決やコネクション(3 way handshake)を毎回行わなくてよくなる。 Goのnet/httpではデフォルトでKeep-Aliveが 有効になっているが、 全体と同一ホストでそれぞれKeep-Aliveするコネクション数が制限される。 これらの値はClientのTransportが持っていて、 これがnullだとDefaultTransportが参照されるので、意識しなければこの値が使われる。 MaxIdleConns: DefaultTransportでは100になっている。0にすると無制限。 MaxIdleConnsPerHost: デフォルト値は2。0にするとデフォルト値が使われる。 同一のホストに同時にたくさんリクエストする場合、2だとほとんど意味を持たない。これを増やして比較してみた。 package main
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
