Site::Reliability::Engineering - YAPC::Hakkaido 2016 SapporoSite::Reliability::Engineering - YAPC::Hakkaido 2016 Sapporo
運用でSSHログインをしなければいけないのは、設計力不足【cloudpack大阪ブログ】 - J.A.R.V.I.S.を作りたい
こんなタイトルですが、私もSSHログインしてます。 というか、shell大好きです。 で、何が言いたいかというと、SSHしなくてもいいように設計しましょう。ということ。 運用中にSSHしなければいけない理由 まず、運用中にSSHをしなければいけない理由は以下あたりかと思います。 設定変更、確認 障害調査、対応 障害調査の場合は、以下などを行います。 サーバへSSH リソース状況を確認する ログを確認する etc...(システム特有の何か) 上記の作業をする上で最も恐れるべきは「オペミス」です。 そして、調査精度は個人のスキルに依存します。 特にオペミスの場合は、再発防止策とかすごく難しいんですよね。 「経験不足」や「本番と開発環境を間違えていた」とか、「手順を間違えた」とか、、、 どう再発防止しましょうか。。。いっその事ログインしない運用とか。。。 「ログインしなければ問題起きないよね」を
ssig33.com - docker ホストを長期間運用する際の注意点
うちには 2013 年末ごろからずっと docker コンテナを運用し続けていた物理ホストがあったのだけど、最近 $ docker ps とかしても結果が戻ってくるのに 20 秒ぐらいかかるし、コンテナの起動とかにも同じくらい時間がかかる $ /etc/init.d/docker restart などとしようもんならコンテナが使用可能になるまで 3 時間ぐらいかかってた。とはいえそう頻繁にコンテナを手動で起動したり終了したりするホストではないし、 docker のデーモン自体を再起動するとかは本当に稀なのでずっと放置してたんだけど、さすがに放置できなくなってきた。 $ docker ps --all | wc -l とすると 103781 とかなってて、ゴミコンテナやイメージが大量にありすぎるのが諸悪の根源なのではないかという予想を立てた。 そこでこのようなスクリプトでコンテナを掃除してみ
【社内資料公開】構築担当者向け 運用チームに引き継ぐ時に気にしてほしい3つのポイント | DevelopersIO
はじめに こんにちは植木和樹＠上越妙高オフィスです。AWS上でのインフラ構築が終わり、アプリケーションがデプロイされるといよいよサービスローンチ。数日〜数週間様子をみて問題がなければ運用チームに業務を引き継ぐことが多いかと思います。 運用チームへの引き継ぎ資料を作って「あとはよろしくね」となるわけですが、その段階で「待て」がかかってしまうことがあります。（だいたい待てを言うのは私なんですが） 今回はスムーズに運用チームに業務引き継ぎができるように、私が注意しているポイントをまとめておきたいと思います。 3つのポイント 注意するポイントは3つです。 1. Input なにをトリガーに作業が始まるのか。どんな通知がくるのか。 2. Action 何をするのか。 3. Output 作業が終わったら誰に報告するのか。 1つずつ説明していきます。 1. Input 運用チームは基本的に「イベント・
成長し続けるインフラの�安定運用事情
『ユーザーストーリーマッピング』 出会いと適用 / User Story Mapping encounter and application
Webオペレーションエンジニアのアウトプットと開発力 - 人間とウェブの未来
という話を、社内のインフラチーム向けにしました。 Webオペレーションエンジニアの大体のイメージについてはこちらを御覧ください。書評なのですが、とてもイメージしやすいエントリになっていると思います。 blog.riywo.com スライドの中でも一応定義していて、３行にまとめると Webサービスの運用 OS・ミドルウェアの運用 運用技術の調査・開発 を主な業務として行っているエンジニアを指すことにします。 入社して間もないので、僕の人格の好き嫌いや人間関係みたいなものがまだできていない頃の発表ということで、素直に内容を聞くことができる、という意味でいい機会だったと思います。 この内容は、社内だけでなく社外のWebオペレーションエンジニアや、所謂、インフラエンジニアと呼ばれている人でも同じような悩みを抱えている人がいるかもしれないと思っていて、内容的にも公開しても良い話なので公開しようと思い
#25歳までに経験しておきたいUNIX管理作業での失敗
案外成功方法より失敗集のほうがタメになりそう． ところでhost名がtaihaなのは安定性に関係ないです!!
#17 うわさのdatabase.ymlをどうしているか カヤックCW編 - KAYAC engineers' blog
こんばんは。クライアントワーク（受託開発）チームのnobu_ohtaです。 この記事は tech.kayac.com Advent Calendar 2014 17日目です。 この記事では、弊社クライアントワーク（受託開発）チームで production 環境で Rails の database.yml と secrets.yml をどう運用しているかを紹介したいと思います。 この話題最近ちょくちょく見かけますが、@mirakuiさんがやっているPodcastの Admins Bar #3: Fluentd, Rails, ActiveRecord でも取り上げられています。 なぜ機密情報をハードコードしないほうがいいか Rails 4.1からsecrets.ymlやdatabase.ymlで機密情報は直書きせずに環境変数から読む設定ファイルが生成されるようになりました。 アプリのリポジト
監視アーキテクチャ(Sensu,Pingdom,Mackerel,StatusPage.io,PagerDuty)についてまとめてみる(2014年12月版) - Glide Note
Sensu Advent Calendarに便乗して、Kaizen Platform, Inc.の2014年12月現在の監視アーキテクチャの話をちょっとしてみようと思う。 モニタリング領域 サービスを監視している領域 Pingdom Pingdom - Website Monitoring 外部ネットワークからのサービスの死活監視。アメリカ、ヨーロッパ、アジアなどの拠点からサービスの死活監視が出来るため、特定の地域からアクセス出来ない場合なのが検知出来る。 後述するstatuspage.ioとの連携で、障害を検知すると、サービスのステータス状況が自動で変わるようになっている Sensu Sensu | The open source monitoring framework. 監視フレームワーク サーバを内部ネットワークから監視するために利用 サーバのプロセス監視、サーバ間の疎通監視、エラ
イマドキのCMSトレンドからWeb運用を再考する
MTDDC Meetup TOKYO 2014 でのセッション 「イマドキのCMSトレンドからWeb運用を再考する」 のスライドです。 話せなかったこともあるので、少し補筆してあります。Read less
JPRS/（緊急）登録情報の不正書き換えによるドメイン名ハイジャックとその対策について（2014年11月5日公開）
--------------------------------------------------------------------- ■（緊急）登録情報の不正書き換えによるドメイン名ハイジャックとその対策 について（2015年5月26日更新） 株式会社日本レジストリサービス（JPRS） 初版作成 2014/11/05（Wed） 最終更新 2015/05/26（Tue） （JPドメイン名におけるレジストリロックサービスの提供を反映） --------------------------------------------------------------------- ▼概要 JPRSでは2014年9月から10月にかけ、国内の組織が運用する複数の.comサイ トが、ドメイン名の登録情報の不正書き換えによるドメイン名ハイジャック の被害を受けたという情報を入手しました。この攻撃手法では
日本MSP協会
2020/09/18 【開催ログ】第三回若手サーバエンジニア（オンライン）交流会を開催しました！ 2019/07/25 【開催ログ】第二回若手サーバエンジニア交流会を東京で開催しました！！ 2019/04/09 【お知らせ】INTERNET WEEK ショーケース IN 仙台 を後援いたします 2019/01/30 【開催ログ】「マイグレーションコンペティション 2019 Winter」を開催しました。 2019/01/29 【学校訪問】「麻生情報ビジネス専門学校」に学校訪問しました。 2018/11/02 【学校訪問】「大阪工業大学」に学校訪問しました。 2018/10/23 【開催ログ】若手サーバエンジニア交流会を開催しました!! 2018/10/09 【学校訪問】「情報科学専門学校」に学校訪問しました。 2018/10/09 【学校訪問】「信州大学」に学校訪問しました。 2018/1
%E8%87%AA%E5%AE%85%E3%81%A7%E5%A4%A7%E5%AE%B9%E9%87%8F%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B8%E3%82%92%E9%81%8B%E7%94%A8%E3%81%99%E3%82%8B
前回 RAID に関するちょっとした話を書きましたが個人が巨大なストレージを運用するにあたって得られたノウハウをだいたい全部書いておきます。 そもそもメリットあるのか？ メリットはあります。金です。 Google Drive は安いですが、それでも 1TB 月 1000 円です。しかし運用にかなり制限がでます。柔軟に使える Amazon Web Service ならその 3 倍+転送量課金です。 16TB だと月 5 万円もかかってしまいます。ちなみにもっとも柔軟に使える EBS だと 16TB で 83000 円ぐらいです。 Google Compute Engine の低冗長性ストレージは S3 より少し安かった気はするけど別にとても安いわけではなかったと思う(よく覚えていないし調べるのがめんどくさい)。 50TB のストレージを Google Drive でごまかしごまかし運用したと
MongoDBでECサイトを実運用する3つのテクニック | Tokyo Otaku Mode Blog
こんにちは。Tokyo Otaku Mode CTOの関根です。 Tokyo Otaku Modeでは、2013年8月からotakumode.com上にカート機能を追加し、決済までをワンストップでできる海外向けECサイトをスタートしました。 どういうシステム構成でotakumode.comが運用されているかを聞かれた時、「Node.js + MongoDBです」と答えると、エンジニアの皆さんは一様にびっくりします。特に驚かれるのが、MongoDBをメインのDBに使用している点です。信頼性に定評があるわけでなく、またNoSQLに対するライトなイメージが一般的にあるため、ECサイトのプロダクションとして使うことに疑問を持たれている方が多いのでしょう。 しかし、十分実用に耐え、日々機能追加が入り成長し続けるスタートアップの環境で、実際に1年間運用してきたECサイトがここにあることも事実です。 そ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RDSでtrx_mysql_thread_idが0のトランザクションが残ってしまったときの対応方法 - Qiita
運用に自動化を求めるのは間違っているだろうか
「運用改善」を考える 〜「自動化」を考える前に
運用を楽にするためのアプリケーションコードを書くということ : sonots:blog
MySQLのバックアップ運用について色々
サービス改善はログデータ分析から
