[B! 運用] teracy_junkのブックマーク

監視について思うとこ - y-ohgi's blog

TL;DR 監視はユーザーにサービスを提供できているかを観測するための行為 SLI/SLOを定めて、SLOを守れるようにモニタリングするダッシュボードは定常的に表示しておくものと障害時に活用するものを作ると良いアラートはレベル分けして人間が対応しなければならないものだけ人間へ通知する監視とはサービスを健全に動作させ続けるために監視を行います。「健全に動作している」の定義はサービスによって異なり、ユーザーにWebページを見せることができることだったり、バッチが正常に終了することだったりします。最終的にユーザーに正常にサービスを提供できていることを観測するために行うことに変わりはありません。さてユーザーにサービスを提供するために何を監視しましょうか？クラウド前提であれば個人的にリソースベース（CPU/Memory）より、 SLI/SLOをベースに監視する事が望ましいと考えてい

teracy_junk 2019/08/20

リンク

Computer Connector Emoji – LINE Emoji | LINE STORE

Mild Turkey This is a Computer Connector Emoji. Used to determine the connector.

teracy_junk 2019/07/11

﹃パソコンの端子の絵文字です。どの端子を使用するのかを判別・説明する時に使用します。﹄目から鱗がボロボロ落ちてる。頭いいな ●運用

リンク

バッチプログラムの運用と監視について検討しよう | メルカリエンジニアリング

こんにちは。メルペイでバックエンドソフトウェアエンジニアをしている id:koemuです。バッチプログラムのお話、今回は運用・監視についてお話したいと思います。当社はすべての業務が24時間行われていますので、システムがオンラインのときに動作するバッチプログラムについてのみ議論します。過去の記事はこちらにあります。運用に備えてバッチプログラムの運用について、﹁プリモーテム﹂﹁実行管理﹂そして﹁ログ管理﹂の3点について述べていきます。プリモーテムポストモーテムという言葉を聞いたことがある方はいらっしゃるかと思います。ポストモーテムとは、GoogleのSRE本の15章*1によれば、障害などの失敗を振り返り、今後に活かすプロセスの総称と捉えることができます。さて、プリモーテム(プリモータム)とは何でしょうか。この言葉は、私が最近読んだThe Manager’s Path*2*3で使

teracy_junk 2019/04/18

リンク

バッチ処理の採用と設計を考えてみよう | メルカリエンジニアリング

こんにちは。メルペイで、決済・振込申請のバックエンドソフトウェアエンジニアをしている id:koemuです。今日は、バッチ処理を行う理由について、考察を深めて設計に活かしていく話をしたいと思います。はじめにバッチ処理とは、ある決まったタイミングで1つのプログラムが複数のデータを一括処理することを指します。この反対の言葉として、オンライン処理があります。オンライン処理とは、お客様の操作を初めとしたイベントをもとに逐次処理されるものです。OLTP(Online Transaction Processing)とも言います。本エントリでは、バッチ処理を採用するにあたり、どういったユースケースが適切なのかを整理して、今後のソフトウェアの設計の指針にできることを目指しています。今回は、﹁バッチ処理を採用するとき﹂と﹁バッチ処理の設計﹂の2つについて取り上げます。バッチ処理を採用する

teracy_junk 2019/02/28

リンク

続・Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん

バッチ処理というのがそれ単体で勉強するのが難しく勉強しようとすると何に手を付けるべきかさっぱりわからないということは、先日のブログで述べたとおり。自分が経験の中で得てきた知見は正しいのかどうか、世間の人に見てもらいたかったというのが書いた動機。そして、新たな視点や指摘をゲットしてより不測の事態を考慮できている最高なバッチを作りたいという目的があったわけだ。で、いろいろな意見をもらったのだけどその中で特に辛いと感じたのはこれ。基幹システムにおけるバッチ処理みたいなものに関する知見については、カジュアルに学ぶ方法はありません。それを体系化した知識として整理した上で、実装できる組織があるんなら、それでメシが食えるんじゃないですかね。— 太一 (@ryushi) 2016, 2月18読んでいると﹁俺達は障害でつらい思いをしてるし当然先人達も障害でつらい思いをしているはずだ。なのに、

teracy_junk 2019/02/28

リンク

タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング #devsumi #devisumiD

2019/02/15 Developers Summit 2019での、森廣の講演資料になります

teracy_junk 2019/02/21

運用

リンク

Krylov部分空間を導入して特異スペクトル変換による異常検知の処理を高速化した - Fire Engine

1年くらい前に特異スペクトル変換法による異常検知ライブラリを作ったんですが、作ったっきり放置していたので、開発当初からやりたかった計算の高速化処理を書きました。ずっと放置してた割にはちょいちょいGitHubのスターを押してもらえてて、データサイエンスの流行を感じた。自分ももう一回ちゃんと学び直していこうという気になったので、まずは昔書いたやつの拡張からやっていく。【目次】特異スペクトル変換とは？ Krylov部分空間の導入検証結果さいごに参考特異スペクトル変換とは？特異スペクトル変換法の特徴については以前のブログに書いているので、ぜひそちらも読んでください。特異スペクトル変換法の全体像は以下のようになっています。出典：上の図は井手剛氏の著書「入門機械学習による異常検知―Rによる実践ガイド」のP200 図7.4を元に作成しました。図のように過去と今のパターンを行列とし

teracy_junk 2019/02/04

リンク

イノベーションを止めずに、端末管理と運用を行う方法 / builderscon tokyo 2018

builderscon tokyo 2018 (https://builderscon.io/tokyo/2018/) 14:20〜トラックE ・なぜ端末管理を行うのかについて・macOS、Windows、iOS、Android 端末管理に関することについて話をしました。発表ノート付きはこちら https://speakerdeck.com/kenchan0130/builderscon-tokyo-2018-034dddd7-02d6-4374-86c3-01b8a93f923d

teracy_junk 2018/09/10

リンク

プロダクトのリリース前から新ダッシュボード「Looker」の導入に踏み切ったわけ | メルカリエンジニアリング

こんにちは。メルペイのデータアナリストチームです。メルペイはプロダクトの開発フェーズにあり、リリースに向けて全社で頑張っています。﹁プロダクトがないのに、データ分析？﹂と思う方もいらっしゃるはずなので、メルペイのデータアナリストの業務と、力を入れているダッシュボードツール﹁Looker﹂の活用について紹介させて頂きます。 Lookerの公式ページはこちらプロダクトがないフェーズでの仕事 Lookerの話をする前に、まずは私達の状況を簡単に説明します。分析チームを抱える企業は沢山ありますが、﹁プロダクトができる前から活動しているケース﹂は少ないと思います。そういった意味では、私達のチームは他の会社と比べてユニークなポジションになっています。一言で言えば﹁事業を作るための分析﹂を行っています。メルペイの事業が成り立つには﹁良いプロダクト﹂を作り、﹁ステークホルダーとの関係﹂を築き

teracy_junk 2018/09/04

運用

リンク

失敗を学びに変える「障害報告書」の書き方 ─ RettyのCTOがGoogleで学んだ「問題を隠さない文化」 - エンジニアHub｜Webエンジニアのキャリアを考える！

失敗を学びに変える﹁障害報告書﹂の書き方 ─ RettyのCTOがGoogleで学んだ﹁問題を隠さない文化﹂人間は失敗するものです。エンジニアもまたしかり。Retty株式会社の樽石CTOが考える、失敗を学びに変える考え方とノウハウを紹介します。はじめまして。Retty株式会社でCTOを務める樽石将人︵ @taru0216︶です。Rettyにおける技術の責任者として不確実性の高いシステム開発を成功に導くよう牽引したり、メンバーが働きやすくなるような仕組みづくりを行ったりしています。子供の頃からパソコンに親しみ、新卒一期生でレッドハットに就職して、Rettyに入社するまでGoogleや楽天を経てきました。エンジニアとして活動して約30年。日々失敗し続けていますし、過去には大規模サービスを止めてしまったこともあります。人間である以上、バグやエラーは必ず起こるもの。エンジニアは失敗を繰り返

teracy_junk 2018/06/29

運用

リンク

障害対応で一番最初にやるべきことは全体への周知じゃね? - Qiita

結構｢障害対応ハウツー｣みたいなのはググればいくらでも記事が出てくるけどここに言及してる記事が案外少ないなあと思ってどうしても書きたくなりました. 新人でもすぐできるからぜひ覚えてもらいたくて｢新人プログラマ応援｣のタグも付けました. 監視ツールの通知によってとか, 誰かに｢このページ見れなくなってるよ｣って教えてもらうとか, 何らかの手段によってエンジニアが障害の発生に気づいたとき, 一番始めにやることは全体への周知だと思っています. ｢一番始めに｣一番始めにというのは, まさに何を差し置いても一番始めにということです. 障害に気づいたエンジニアはつい｢どこのページだ｣｢レスポンスタイム10秒って出てるけどホントかよ試しに俺もアクセスしてみよう｣｢さっきのデプロイが原因じゃねえか?｣などと口走りがちですが, これらの気持ちをグッと堪えてまずは周知に意識を向けるべきです. ｢全体

teracy_junk 2018/06/29

運用

リンク

フロントエンドの負債と向き合う - mizchi's blog

某所で書いたものを公開用に書き直したもの前提フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない

teracy_junk 2018/03/20

『フロントエンド開発で、最初に考えるべきは、 lint ルールを追加するコードフォーマッタを入れる型を書くこれらは比較的痛みがない。』

リンク

java-monitoring

JJUG ナイトセミナーの登壇資料です。 https://jjug.doorkeeper.jp/events/69650

teracy_junk 2018/01/25

java
運用

リンク

目指せ！落ちない高可用性サーバ、ハードウェアの選び方 - Qiita

10年以上金融機関で働いているインフラエンジニアの落ちないサーバにするための考察です。ハードウェアの専門家ではないので、正確ではないかもしれません。今までの経験からの個人的考え方になります。私たちオンプレ重視のインフラエンジニアは、クラウドサービスではできない高可用性サーバを導入したり、複数台構成で1台故障しても問題ない構成のサーバはコスト重視するなど、システムに最適なサーバを導入しようとしています。高可用性サーバを追求する目的 ■アプリに影響を与えないように Active/Standby構成にしていて、インフラ的にはダウンタイムが数秒だとしても、アプリによっては復旧に時間がかかったり、問題ないことの確認にも時間がかかってしまいます。また、正しくサーバが落ちればアプリが問題ないとしても、サーバが中途半端な状態のままになってしまい、なんだかおかしいということもあります。

teracy_junk 2017/07/20

リンク

冗長化の難しさとNetflixの答え｜こんぴゅ

この世には、ダウンすることが許されないシステムが存在する。金融機関の基幹系、原子力発電所や鉄道の制御システム、流通業の物流管理システムなどはもちろんであるが、最近ではtoCのサービスでもダウンタイムが長くなると大事件として騒がれ、ヤフトピに載ってしまったりする。ではダウンへの対策はどうするかというと、いくつか手法はあるのだけど代表的なのは「冗長化」である。簡単に言うと、全く同じシステムを裏側に待機系として用意して、有事の際は自動的に切り替わるようにしておくのである。素朴だが、殆どのシステムではこの種の仕組みを用意している。それでうまくいけばいいのだけどじつは、この待機系への切り替えというのは鬼門であり、高確率で失敗する事になる。［続報］東証のシステム障害、原因はハードウエア故障後の切り替えミス http://itpro.nikkeibp.co.jp/article/NEWS/2012

teracy_junk 2017/05/23

運用

リンク

一般的なチートの手法と対策について

スマホゲームのチートにはメモリの改ざんを利用するお手軽なものに始まり、パケットの改ざんやコードの改ざんまで、多様な手法が存在します。しかし、それらがインターネットや書籍で語られることは多くはありません。これまでのDeNAのセキュリティチームの経験を基に、それぞれのチート手法を説明したあと、どのように対策をすれば良いのか、ご紹介させていただきます。

teracy_junk 2017/03/22

リンク

「障害に捨てるところなし」というお話をしました - Cybozu Inside Out | サイボウズエンジニアのブログ

どうも！アプリケーション基盤チームの@yokotasoです。3月11日にBattle Conference U30 というイベントでお話をさせていただきました。準備がてら作成したディスクリプションを公開します。キーノートはSpeakerDeckからどうぞ!こちらも参考にしていただければ、嬉しい限りです。では、どうぞ！障害にすてるところなしサイボウズ株式会社の横田です。﹁障害に捨てるところなし﹂というタイトルで少しお話させていただきます。お手柔らかによろしくお願いします。運用障害の話まずはじめに、今回のお話をするにあたりまして運用障害でご迷惑をおかけしたみなさま、大変申し訳ありません。より快適に利用いただけるサービスを目指しまして、対策・改善をおこなっております。これからも、弊社製品をよろしくお願いいたします。クラウドの規模と稼働率障害の話をする前に、サイボウズの

teracy_junk 2017/03/16

リンク

ちゃんと復旧できる、GitLabのバックアップ運用方法 ─ GitLab meetup #01レポート - pixiv inside

2017年3月2日︵木︶、都内では初のGitLabのイベント﹁GitLab meetup in Tokyo #1﹂が開催されました。記念すべき第一回のイベントは、ピクシブのオフィスで開催され、約140名の参加があるという大盛況っぷり。ピクシブからは、2名のエンジニアが登壇しGitLabに対する知見を発表しています！そのうちの一人。2013年にピクシブへ入社した金子達哉、ニックネームはcatatsuy。彼が同イベントで語った、GitLabのバックアップや、バージョンアップの運用に関する知見を、本記事にてご紹介します。 GitLabのインストールは難しい？ GitLabとは、プライベートなgitリポジトリの管理画面やレビュー画面を提供してくれるWebアプリケーションです。GitHubやBitbucketのようなことが、自社のサーバで行えます。自社のサーバーにインストールして運用することがで

teracy_junk 2017/03/15

リンク

Googleのインフラ技術から考える理想のDevOps

デブサミ2017で発表予定の資料です。 http://event.shoeisha.jp/devsumi/20170216 2017/02/14 ver1.0 公開Read less

teracy_junk 2017/02/20

リンク

闇のDevOps DevOpsと業績評価 – ところてん – Medium

ここから、DevとOpsが協力すればより効率的になる＝DevOps、という言葉が生まれました。当時は大企業においてはDevとOpsが分かれていることが当たり前だったのです。そして、大企業における当たり前が、当たり前ではないことに気付き始め、DevOpsを実現するためのツールができ始めたころでもあります。ではなぜ、大企業ではDevとOpsが分かれているのが当たり前だったのでしょうか？ハードウェアの時代その昔、産業の主役はハードウェアでした。そのため、多くの企業はハードウェアを作ることに対して最適化が行われました。ハードウェアには研究開発、製造、運用サポートといった大きな区分けが存在します。そして、それぞれの仕事において要求する人材レベルは異なります。加えて、大量生産された製品の運用サポート︵設置作業員、サポートセンタ︶には、大量の人員が必要になってきます。したがって、組織を研究

teracy_junk 2017/02/14

『DevOps云々の前に、なぜDevとOpsが対立するのか、というあたりまえの前提を理解していない』『DevOpsはOpsの仕事をDevが奪うこと』

リンク

はてなブックマーク

タグ

関連タグで絞り込む (46)

運用に関するteracy_junkのブックマーク (63)

お知らせ

今週のはてなブックマーク数ランキング（2024年7月第1週）

月間はてなブックマーク数ランキング（2024年6月）

今週のはてなブックマーク数ランキング（2024年6月第5週）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス