すべての人類が読むべきマンガ、フラジャイル【SREと病理医の共通点のお話】 - okadato の雑記帳
この記事は SREアドベントカレンダー 2019 11日目の記事です。 テック要素ゼロ・エモ全振りの内容なので、SRE以外の方にもぜひご一読いただきたいです！ 【追記】 SRE とは Site Reliability Engineering の略です！詳細は弊SREチーム Mng のコチラの記事をご覧ください！ 改めましてになりますが、スタディスト開発部はSREチームに所属のおかだと申します。 突然ですがSREとして働いているみなさん、月刊アフタヌーンで連載されている「フラジャイル 〜病理医岸京一郎の所見〜」というマンガをご存知でしょうか？ 2016年には長瀬智也さん主演でドラマ化もされた作品です（ぼくは原作しか読んでいないのですが…） 病理医という（ちょっとマイナーな？）職業がテーマの、個人的に超イチオシのマンガです！！ まずは作画をなさっている恵三朗さん（@36_Megu）の Twit
SREとして仕事をしていて最近思うこと - ROBOT PAYMENT TECH-BLOG
この記事は Qiita の SRE Advent Calendar 2019 7日目に寄せて書きました。 こんにちは。請求管理ロボシステムチームの @trunkatree です。 今回は私の所属するSREチーム（私と @j_untanaka さん）が仕事をしていて最近思うことをまとめてみます。若干フワッとした内容ですが、毎日つづく Advent Calendar の息抜きだと思ってどうかお付き合いください。 前置き クラウド時代は情報収集が大切 SaaSに合わせる設計思想 終わりに 前置き 最初に自己紹介がてらチーム体制について注釈させてください。 私たちは「請求管理ロボ」という SaaS を自社で開発運用しています。サービスや基盤の概要はこちらの記事（ 請求管理ロボシステム基盤の概要 ）をご確認いただければと思いますが、システムはAWSで動いています。 システムチームでは現在10名のエン
CAMPFIREにSREを導入した話 - Qiita
こんにちは、CAMPFIREでSREをやっている岩崎です。SRE Advent Calendarということで、この一年でチームにSREを導入した話について書こうと思います。 SRE導入の経緯 自分が社内でSREとして活動を始めたのは一年ほど前に遡ります。当時のCAMPFIREは急速に成長しているベンチャー企業といった感じで、成長のスピードに仕組みが追いついておらず、色々と未整備な状態でした。 インフラは基本的に開発エンジニアが兼任するケースが多く、明確な担当者がいませんでした。また、運用ルールもあまり整備されていませんでした。 チームにSREを導入したというと華々しく聞こえるかもしれませんが、実際にはSRE以前の問題も多く、泥臭いことも結構やりました。私自身SREについて日々勉強している身ですし、SREは魔法の杖でも銀の弾丸でもありませんが、これから同じようにSREを導入しようとしているチ
タップルSREにおけるSLOの取り組み - Qiita
皆さんこんにちは。 マッチングアプリ、タップル誕生でSREをしている袴田です。 本日は『タップルにおけるSLOの取り組み』と題して、弊社SREがどのようにSLOを運用しているか説明します。 システム品質の目標値であるSLO SLOを一言で言えば、システム品質の目標値です。 e-wordsによるSLOの定義は以下の通りでした。 提供するサービスやサービスを構成するシステムや機材などに関して、性能や可用性、データ管理、運用体制、サポート体制、セキュリティなどの目標水準や目標値を設定し、利用者に提示する。 参考:http://sp.e-words.jp/w/SLO.html SLOを利用して期待値をコントロールする SLOを利用することで、システム提供者と利用者間の期待値をコントロールできます。システム利用者からすれば、不具合ゼロのシステムを期待しますが、そのようなシステムは存在しません。システ
実践！ポストモーテム - pixiv inside
みなさんこんにちは！ピクシブで唯一のテスト専任エンジニアの @shimashima です。 前回、「品質“実質”無料キャンペーン」を開始しました という内容で社内横断的な品質向上の取り組みを紹介しましたが、今回はキャンペーンの一環として行ったポストモーテムの取り組みについてご紹介します。 目次 ポストモーテムとは ポストモーテムの目的と効果 開催方法 実際のポストモーテム事例 おわりに ポストモーテムとは ポストモーテムとは、直訳すると検死となりますが、そこから転じて何か問題が発生した際に行うふりかえりのひとつです。問題が発生し収束した後に、落ち着いた状態で客観的に事象を振り返りを行い、認識合わせや原因の確認、再発防止などを検討していきます。 私が以前参加していた金融系SIでのプロジェクトでは特に再発防止の意識が高かったため、プロジェクト終了時に必ずポストモーテムを行い、プロジェクト内で発
データエンジニアリングにおける人事評価基準 - 下町柚子黄昏記 by @yuzutas0
じゆうちょう Advent Calendar 2019 18日目の記事です。 概要 データエンジニアリングという業務を扱うにあたって、どのように人事評価を実施するか。 本稿では実践可能なレベルで「評価基準」の例を提示します。 もくじ 概要 もくじ 背景 注意点 本題: 人事評価の設定例 1. マイルストーン（計画） 2. QCDS（構築） 3. サービスレベル（運用） 4. 利益目標（企画） まとめ Appendix 前提1: 本稿のスコープ ＝ 査定でボーナスが上下するような状況 前提2: 被評価者がコントロールできない事象に対してはフォローする 応用編1: 「データ基盤」という固有トピックにおける技術や案件の評価について 応用編2: 「データの民主化」の目標設定をどうするか おわりに 背景 データエンジニアリング業務に伴う「人事」（採用・アサイン・育成・評価）について質問を受けることが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
