ソフトウェア設計の言語化スキルを磨くこと｜qsona
たとえば設計について議論するときや、コードレビューで指摘をするときに、「なぜその設計が良いと思うのか？」について言語化するのが上手だと、確実に良いことがあります。 言語化が上手にできるかが一つの壁なのではないか、と感じることもあります。後輩を育てたりチームをリードするような立場になると、特に必要性を感じるのではないかなと。 自分も、うまく言語化できたことですんなり議論を進められていると感じることは多いですし、逆に直感的な良さを言語化できなかったことで直感に反する方向に進んでしまい、結果よくなかったというような苦い経験もあります。 前提: ソフトウェア設計の良さは静的には決まらない良い設計・良いコードとは何なのか。という質問に一言で答えるなら、「保守性が高い」ことだと思います。つまり、今後の変更・拡張を、高速にバグが少なく行えるような状態が良い設計・良いコードです。(一般的にはこれで70%く
可用性とどう向き合うべきか、それが問題だ : CRE が現場で学んだこと | Google Cloud 公式ブログ
この『CRE が現場で学んだこと』シリーズでは前回、ロード シェディングという手法で「成功による障害」を切り抜ける方法について紹介しました。これに対して素晴らしいフィードバックをたくさんいただきましたが、その中に、いかにして数値を事業目標と結びつけるべきかという質問がいくつかありました。 そこで今回は、最初の原理に立ち戻り、そもそも成功とは何を意味するのかを追究し、実際にシステムが成功しているかどうかを把握する方法について考えてみたいと思います。 成功の前提となるのは可用性です。可用性のないシステムは機能を実行できませんし、最初の段階で失敗します。では、可用性とは一体何なのでしょうか。まずはこの言葉を定義しなくてはなりません。 可用性とは、システムが意図した機能をある時点で実行できるかどうかということです。可用性の測定はレポーティング ツールとして活用されるほか、過去の可用性を見ることで、
SLO、SLI、SLA について考える : CRE が現場で学んだこと | Google Cloud 公式ブログ
前回の『CRE が現場で学んだこと』シリーズでは、システムの可用性を担保するにあたってターゲットとする正確な数値をいかにして割り出すか、ということについてお話ししました。このターゲットをシステムのサービス レベル目標（SLO）と呼びます。 今後、システムが十分な信頼性を保って稼働しているか、またシステムにどんな設計やアーキテクチャの変更が必要かについて議論する際は、システムが継続的に SLO を満たしているという枠の中で語る必要があります。 SLO の適合性は直接測定することが可能です。システムにおいて精査が成功した頻度で計るのです。これをサービス レベル指標（SLI）といいます。システムが過去 1 週間 SLO を満たしつつ稼働していたかどうかを評価する場合に、SLI からサービスの可用率を把握するのです。定められた SLO を下回っているとなれば問題があるということですから、他の場所に
メルカリのWeb MicroservicesにおけるSLI/SLO - Mercari Engineering Blog
Mercari Advent Calendar 2018の24日目はメルカリBackendエンジニアの@sota1235がお届けします。 現在、私はWebのシステムをリプレースしMicroservicesアーキテクチャに移行するチームで働いています。 メルカリのMicroservicesアーキテクチャでは各Microserviceチームが責任を持ってSLI/SLOを定め、運用する必要があります。 このSLI/SLOを決める過程でいくつかの学びや難しさがあったのでそれをお話しようと思います。 SLI/SLOとは SLI(Service Level Indicator)とはサービスの品質を測るための指標です。 そしてSLO(Service Level Objective)とは各SLIに対しての目標数値です。 例えばSLIを全リクエストの50xエラー以外の割合として、SLOは99.99%とする、
インフラのボトルネックについて知る - ぺい
インフラのボトルネックを理解する コードはもちろん、リリースしてから安定して動かせるように面倒を見るまでが仕事というのが、弊社の開発スタイルなので、そこで最近学んだことについて、文献や自分の実体験からボトルネックに関する考え方をまとめてみた。 CPUボトルネック CPU使用率に対する基本的な考え CPU使用率が80％から90%をずっと推移している！と聞くと、自分のPCの感覚だと、「やばそう」という感覚に陥りますが、インフラにおいての使用率はそうとも限りません。 CPU使用率高い: うまくリソースを使い切っている CPU使用率低い: オーバースペック ただ、高いCPU使用率にも許容出来る度合いがあったりもするので、そこらへんの判断軸などを踏まえて、まとめてみる。 現実世界の例 CPU使用率が高い状態というのは、実世界に置き換えると、店員がみな忙しく働いているという状態です。利用者からすればオ
XARs: An efficient system for self-contained executables – Facebook Code
Distributing large pieces of software to thousands of machines with a wide variety of configurations can pose a significant operational challenge, requiring a process to identify and copy precisely the right combination of dependent libraries and data files for each device. To make this faster, more robust, and more efficient, we have developed and deployed XARs, or eXecutable ARchives, a system f
Microservices と会計システム | メルカリエンジニアリング
この記事は、 Mercari Bold Challenge Month の18日目の記事です。 こんにちは。メルカリで Product Manager として働いている津田と申します。私は社内で「会計システム」と呼ばれる、会社が運営するサービスに付随して発生した債権債務の増減を記録・集計するシステムを開発するチームで働いています。 はじめに メルカリでは、お客さまの行動に応じて日々さまざまなお金の流れが発生しています。たとえばメルカリで商品が出品され購入された（取引が行われた）場合を考えてみます。 この取引は、会社から見るとそれぞれの相手先に対する債権債務関係の変化と捉えることができます。メルカリにとっては、購入したお客さまに対する債権（= 商品代金）と出品したお客さまに対する債務（= 売上金）が発生します。このとき、商品代金の一定割合（通常は 10%）が販売手数料としてメルカリの売上とな
ISUCON9 予選敗退した - すぎゃーんメモ
ISUCON9。今年は縁あって声かけていただき id:Soudai さんと id:kamipo さんと、「失敗から学ぶISUCONの正しい歩き方」というチームで出場した。 練習会 インターネット上でよく知っている人たちとはいえ 実際に一緒に仕事をしたことも無ければチームを組んで一緒に何かをしたことがあるわけでもない。 予選の2週間前に一度集まって、1日かけて前年の予選問題を再現しつつ試し解きしてみる、という会をした。 言語は3人で共通した得意なものがあるわけではなかったので とりあえずRubyで、ということにした。 そのときの感覚では「やっぱり色んなところで躓くこともあるかもしれないけど 正しく計測して早めに大きな方針を決めて改善をしていけばそれなりの成績には辿り着けるだろう」という感じ。 DB関連はとにかく2人が強いので、自分はアプリケーションコードを如何に正確に早く書いていけるかが勝負
ISUCON9予選ふりかえり - かみぽわーる
なにもできなかったし書くことないわーって思ってたけど、チームのふりかえりをGitHubのissueに書いてたらふつうにこれ外に書けばいいなってなったのでここに記す。 アクセスログから得られる情報の解像度が相対的に低くなってきたと感じた。ざっくりどのエンドポイントが遅いとか何回叩かれてるとかの概観を知るのは依然として重要だけど、近年は遅いエンドポイントの処理はめちゃくちゃ複雑になってきていて、たとえば/buyが遅いぐらいの情報の解像度では情報量が足りてなかった。 外部APIへのリクエストが絡むような問題への心の準備とかできてなかった。なんなら準備してきてないし予選では出ないでほしいなとか思っていた。 プログラマとしての筋力が足りてなかった。たとえばアクセスログからの情報では足りないってなったときにときにじゃあやばそうなところ全部にprint文書いて測るわ！ぐらいの気概が必要だった。外部リクエ
【ノーカット掲載】オンプレミスかクラウドか。社内を二分する論争にDeNA南場智子が出した"答え" | フルスイング by DeNA
コスト・品質ともに最高レベルを実現していた、DeNAのオンプレミス。しかし2018年6月、DeNAは全社方針としてそのオンプレミスを捨て、3年の移行期間をかけクラウドに全面移行することを決定しました。 なぜDeNAは経営の意思決定として、当初「3倍のコストになる」と言われたクラウド全面移行に踏み切ったのか？ 本記事では「クラウドシフト決定の判断」に至る経営者の思いを語った『Google Cloud Next ’19 in Tokyo』でのDeNA代表取締役会長 南場 智子（なんば ともこ）講演内容をノーカット掲載します！ 「経営の言語」と「技術の言語」両方話せる人材を信頼する 私がDeNAを立ち上げたのは、1999年。今からちょうど20年前です。もともと、経営コンサルタントをしていました。得意なのは戦略や提携。それからマーケティングや分析などですね。一緒に起業した仲間も、同じファームから連
はじめて国際会議で論文発表して考えたこと - ゆううきブログ
先日、アメリカのウィスコンシン州ミルウォーキーで開催された国際会議 IEEE COMPSAC 2019で時系列データベースHeteroTSDBの論文を発表してきました。 IEEE COMPSACは、IEEE内のコンピュータソフトウェア分野の分科会IEEE Computer Societyのフラグシップカンファレンスとして開催されている国際会議です。 COMPSACが対象とする分野は、ソフトウェア、ネットワーク、セキュリティ、アプリケーションなど非常に幅広く、様々なテーマの発表がありました。 COMPSACは、メインシンポジウムと併設のワークショップにより構成されており、メインシンポジウムのregular paperの採択数は63本(24.5%)、short paperの採択数は50本となっています。 投稿時にregularとshortの区別はなく、今回の我々の論文は、メインシンポジウムのs
知らない技術は怖い - Mitsuyuki.Shiiba
AよりB、CよりD 今後の方向性を決める判断の中で「Aという技術ではなくBを採用する方がが良さそうです」とか「既存システムのCは良くないからやめてDを使うようにしましょう」とか。最近、何人か全然別の人からそういう話を聞く機会があった。 AよりBが良さそう？ 「僕はAの方が良いと思うんですけど、Bの方が良さそうだと思う理由を知りたいです」って聞くと「Aはこういう部分に問題があると思います」って言われて話が噛み合わなくて、しばらく話をして気づいた。 この人、Aを触らずに想像だけで喋ってるんだ。ってことに。なので、実際に動かして見せてあげると「あぁ、それならAの方が良いですね」ってなった。 「興味があるだけなんですけど、僕も知らない技術だったので少しドキュメントを読んで実際に触ってみて機能を確認してからAの方が良いなと思ったのですが、どうして触らずに想像だけでAは問題があるって断言したんですか？
マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき
ミスとかトラブルとか - 最速配信研究会(@yamaz)
UIEUEIのid:shi3zさんがミスについての話を書いておられる(会社名間違えてました.大変失礼しました. > shi3zさん). 部下が致命的なミスをするのは全面的に上司の責任 1行でまとめると「ミスは必ずおきるので,ミスを事前に検知する仕組みが必要だよ」ということなんだけど,私も前職ではありとあらゆるミスやトラブルに遭い,それに対して思うところがあるので,どう対処してきたかを書いてみようと思う. このエントリは長くなりそうなので,先に「今来た3行」でまとめるとこんな感じになる. ミスやトラブルはありとあらゆる隙間を縫っておきるので,確率的なものととらえる方がいいよ. ミスやトラブルがおきた時の影響を最少にするためにはミスやトラブルを検知することの他に,「そもそもそんなミスが起きえないようにする」,「万一そのミスがおきても大丈夫なようにする」為の仕組み作りが重要だよ. 根性論に頼るの
エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba
最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。 なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え？そこは問題ないと思いますよ？」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。 可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、「ここは
ヤフーを退職しエムスリーに入社しました｜ばんくし｜note
外から見ていて分かる通り、技術的、学術的に尊敬できる方が居るのはもちろん、社員の多くがギークです。また、機械学習を使った貢献のしがいのある医療という分野であることが私にとって魅力的でした。 転職後もMLエンジニアとして、常に勉強し、色んな事にチャレンジし、多くの成果で貢献出来ればと思っています。何卒よろしくお願いします。 以下の記事では、転職活動で使っているサービスや履歴書、現在持っている成果、具体的な報酬、次の会社に求める想いについて書きました。 これ以降は、上記記事でボカシた転職を考えるまでに至った理由だとか、結果としてどんな転職活動だったかを書くものです。 なぜ転職なのか前回ボカシた部分から書くと、転職を考えた理由は主に以下の3つです。 ・自身の上司が勉強できていない事に気付いた ・USでの研修で受けた刺激 ・自分に足りないものとチャレンジ3つの理由は横串で繋がってるんですが、細かく
人事の超プロが明かす評価基準 を読んだ & エンジニアの評価基準について - HsbtDiary(2019-02-27)
■ 人事の超プロが明かす評価基準 を読んだ & エンジニアの評価基準について 去年 @pyama86 さんが読みやすくて面白かったと話していたので買ってシュッと読んだ。 確かに面白くて、コンピテンシーという考え方はなるほどなって感じだった。いろんな立場の人が組織にはいるけど、より管掌や責任の範囲が広い人は狭い人ができることは当たり前とした上で、立場にあった評価の基準が重なっていくという話で、自分も含めて「わかるー」という感じだった。 後、この本では評価を決めるのは影響力というくだりがあって、これは特に専門職に分類される人には読んでもらいたいところなんだけど、エンジニアの場合だとシニアエンジニアは「技術力が高い」から評価されるのはなく「技術力が高いので結果として生み出されるアウトプットの影響力が高い」から評価されると置き換えるとわかりやすいと思う。 「アウトプット」と言われると OSS であ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Where Chaos Engineering comes from, and what's next
RailsDM2019: On the lonely rail of Engineering Management
DevOps, Immutable Infrastructure, Microservices and Chaos Engineering
