SRE Tech Talks ( http://connpass.com/event/34825/ ) でお話した際の資料です
たったひとつの「プッシュ通知」の改善で、300万人がつかうSNSアプリの、KPIが倍増した話(論理的に正しいことが、ユーザーにとってベストとは限らない) 少しまえですが、NYタイムズに「Wishborn」というアプリの、おもしろい運営エピソードがのっていたので、簡単にメモしておきたい。 論理的に正しいことが、ユーザーにとってベストとは限らない。「Wishborn」というアプリ(「写真投票SNS」という感じ)では、MAU 300万人いて、若いユーザーたちにつかわれている。 この「Wishborn」をつくっている、おじさん開発者たちは、こう考えていた。「あまりにたくさん、プッシュ通知がくると、ユーザーはイライラする」 これは論理的に正しいのだけど、実はユーザーはそうは思っていなくて。「プッシュ通知をバラバラに、すべて通知してほしい」と考えていた。 スマホネイティブたちにとって、「いいねがつきま
これはきかんしゃトーマスアドベントカレンダー20日目の記事です. サービスやシステムが運用・運営フェイズに入るとほぼ間違いなく事故が起きる.理想的には事故が起きないことがベストだがそうした状況はほぼ間違いなく存在しない,つまり事故はいずれ起こるので,我々はそうした不慮の事故に備える必要がある.上の動画は今,社内の一部で流行っている歌で,非常に示唆に富んでいて,良い. さてスタンスを予め明らかにしておくと,事故やオペミスは起こるものだし,その点については仕方がない事だと思っているが,その事故からは学習すべきだと思っている. 事故が起きた時はそれをいち早く終息・復旧させることが再優先だと感じていて,それを遂行するためには手段を選り好みせず,かつ冷静に行うことが重要だと思う. よく「犯人探しをするな」みたいなことを言われるけど (まあ犯人という言い方は悪いんだが) 実際に事故を起こした人から話を
「ノートパソコンをサーバにしたら性能はデスクトップ並だしUPSついてるし 静かだしいいよ」なんてお馬鹿なこと言いだす人が絶えません。物には適材適所ってものがあるんですよ。 ※知らない人のために書いとくと「サーバー」がやってることって、ソフト次第でその辺のノートパソコンでもほとんど同じことができるんだけど、その辺のノートパソコンではWindowsだろうとLinuxだろうとサーバとしてはまともに使えないよっていう話。 — 元記事を書くより前~2010年ごろまで、うちの職場ではいろんな部署で少し古くなって個人のデスクで使われなくなったノートPCを部内サーバとして勝手にファイルサーバやプリントサーバやアプリサーバにしていました。それこそシステム部のようなのが無いのでやりたい放題。一見うまく動いている、動かせているように見えるのだけど… ※だったらそれでいいじゃん的な自称SIerはどこにでもいる。
AWS は Management Console や API ですべて操作できます(Direct Connect など一部例外もあります)。データセンターの物理的なセキュリティなどは AWS が責任を負うところで、ユーザーはまったく意識する必要はありません。 その代わり、OS やミドルウェアの管理、アプリケーションの設計や実装、適切な権限管理などはユーザーが責任を負うところです。 今回はあまり取り上げられないけど、すごく大事な権限管理についてまとめてみました。自分が仕事で関わっているプロダクトで権限管理を見直すときに調べたことをベースにしていますが、もっと良いプラクティスがあればぜひ教えてください。 AWS アカウントは使わない 普段の運用で AWS アカウントは使いません。 AWS アカウントとは、最初にサインアップするときに作られるアカウントです。 このアカウントは Linux で言う
価値のある機能をユーザに早く届けるための大企業エンジニアの挑戦 / Achieving Faster Delivery of Customer Value Features in a Siloed Organization
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く