URL

「書評: Site Reliability Engineering · re-imagine」のグラフ

書評: Site Reliability Engineering · re-imaginehttp://torumakabe.github.io/post/bookreview_site_reliability_engineering/
月のグラフ

コメント

(2018/06/21 09:37:34 更新)
  • SREについて。良い。:iga_k2017-06-21 15:25:21
  • SRE:Site Reliability Engineering:akakit2017-02-21 18:55:57
  • 今話題のSREってなんじゃらほいって思ってたのでなんとなくイメージ出来ました:girled2016-06-29 11:30:43
  • 日本語の概要だけでも読むといいと思った:d4-19772016-04-17 09:44:57
  • 書評はやい。。。SREだけでなくサービスに関わるすべての人間にとって参考になる本だと思う。自分はまだ4章なので先は長い。:restartr2016-04-16 23:30:06
  • ここにある概要を読むだけでもいろいろと考えさせられる。:june292016-03-29 10:55:52
  • >日々のリアクティブな活動に忙殺されるインフラ/Ops担当はどうしても減点評価になりがちだが、仕事の半分がプロアクティブな活動であり、成果を加点評価できる。昇格、昇給の根拠になりやすい。:raimon492016-03-29 09:56:20
  • 興味深い。運用と開発でError budgetを共有して減点方式じゃなくすっての、いいな。:progrhyme2016-03-28 23:17:22
  • 興味深い。運用と開発でError budgetを共有して減点方式じゃなくすっての、いいな。:key_amb2016-03-28 23:17:22
  • 203:garage-kid2016-03-28 15:10:25
  • “インシデント対応、問い合わせ対応、手作業は仕事の50%に収まるように調整する”←いきなりハードル高すぎワロタw・・・・・ワロタ。。。。:oooooo41502016-03-28 14:07:28
  • "アプリ/製品チームとSREチームは”Error Budget”を定義、共有する。これは四半期ごとに定義される、サービスレベル目標である。ユーザがサービスを使えなくなると、その時間が、このError Budgetから取り崩されていく。":suzu_v2016-03-28 14:06:12
  • 書評出た。早い。日本語版を出すだけの需要があるのかは謎。追記: 中の人いわく、世界で最初の書評らしい。:tsekine2016-03-28 14:05:52
  • 書評: Site Reliability Engineering · re-imagine:synchro8002016-03-28 14:04:17
  • 書評: Site Reliability Engineering · re-imagine:chronosfm2016-03-28 13:24:19
  • 気になる:kaputte2016-03-28 12:46:16
  • Error Budget の網羅的な可視化やりたい:halfrack2016-03-28 12:16:51
  • こういうのやりたいなぁ、と思う:fjwr382016-03-28 11:59:42
  • “サービスごとにアプリ/製品チームとSREチームがError Budgetを共有することで、利害関係を一致できる。”:keepkeptkept2016-03-28 09:59:50
  • ざっと書評見た感じ、良書っぽい。:luccafort2016-03-28 09:04:10
  • "アプリ/製品チームとSREチームは”Error Budget”を定義、共有する。これは四半期ごとに定義される、サービスレベル目標である。ユーザがサービスを使えなくなると、その時間が、このError Budgetから取り崩されていく。":YuichiTanaka2016-03-28 09:03:22
  • 「Error Budgetを共有することで、利害関係を一致できる」これいいねー!:tdtsh2016-03-28 08:59:33
  • Error Budgetの大きさはサービスごとに異なり、定義は製品チームの責任。当然Error Budgetが少ない = サービスレベルが高い = コストがかかる ので、製品チームはいたずらに高いサービスレベルを定義しない。:tinsep192016-03-28 08:52:28
  • Error Budgetを共有することで利害関係を一致できるのは面白い。重視するものが違うからこそ製品チームに定義が委ねられるというのも。:kimutansk2016-03-28 08:44:47
  • 「日々のリアクティブな活動に忙殺されるインフラ/Ops担当はどうしても減点評価になりがちだが、仕事の半分がプロアクティブな活動であり、成果を加点評価できる。昇格、昇給の根拠になりやすい。」よさげ:naka-06_182016-03-28 08:02:43
  • “インフラ/Ops担当は「サービスを少しでもダウンさせたら悪」となりがちだが、サービスごとにアプリ/製品チームとSREチームがError Budgetを共有することで、利害関係を一致できる。”:ryuzee2016-03-28 07:48:36
  • “アプリ/製品チームとSREチームは”Error Budget”を定義、共有する。これは四半期ごとに定義される、サービスレベル目標である。ユーザがサービスを使えなくなると、その時間が、このError Budgetから取り崩されていく。Budge:mizoguche2016-03-28 07:04:20
  • いたずらにサービスレベルを上げることだけを考えないのは良い:suthio2016-03-28 06:42:03
  • “Googleのインフラ/Ops系技術チームの働き方や考え方を題材にした本”:mukaken2016-03-28 03:15:14
  • "日々のリアクティブな活動に忙殺されるインフラ/Ops担当はどうしても減点評価になりがちだが、仕事の半分がプロアクティブな活動であり、成果を加点評価できる。" モチベーションもあがりそう:amagitakayosi2016-03-28 03:13:50
  • Error Budget の考え方いいな:mirakui2016-03-28 00:26:49
  • 読まねば:kazeburo2016-03-27 23:03:10
  • "インシデント対応、問い合わせ対応、手作業は仕事の50%に収まるように調整する。残りの時間は自分たちの仕事をより良く、楽にするために、コードを書く。":doi-t2016-03-27 22:12:53
  • "書評: Site Reliability Engineering · re-imagine":shiwork2016-03-27 22:01:30
  • ほー。:iekusup2016-03-27 21:57:58
  • 書評: Site Reliability Engineering · re-imagine:straight_punch19902016-03-27 21:12:58
  • "Error Budget" って考え方は深みがある.日本語翻訳出るとしても相当後だろうなぁ...原著で読もうか:kakku222016-03-27 20:55:28
  • []読みたい:y_uuki2016-03-27 20:45:41

関連エントリ