2014-11-01 渋谷Ruby会議01 http://regional.rubykaigi.org/shibuya01/Read less
6月末頃、Rails/Rubyのバージョンアップ作業を開始したときに、Railsアプリケーションを長い間運用しているサービスってなかなか聞かないよな〜と思って、Facebookで下記のような投稿をしてみました。 すると、「AWSを活用してる現場リーダーやCIOをお招きしたトークイベント」でパネルディスカッションをさせていただきました のイベントでお世話になった小山田さんがすぐさまトークイベントを持ちかけてくださり、今回、 約10年最新版のRailsに追従してきた運用ノウハウをビール片手に聞きましょう! - Web系な人のキャリアカフェ | Doorkeeper というイベントでお話させて頂くこととなりました。 当日は、社内SNS『SKIP』のサービス開発/運用でやっている取り組みを例に、Rails,RubyなどのバージョンアップからOSのアップデートを実施する際の取り組みについてご紹介させ
今から2年前の2012年の6月20日、レンタルサーバー会社のファーストサーバは、大規模な顧客データの消失事故を引き起こした。あのときなにが起こったか? ファーストサーバのさまざまな部門の担当に、当時の状態を振り返ってもらった。 ファーストサーバは今も変わらずビジネスを展開している ファーストサーバの顧客データ消失事故に関するドキュメンタリーを書きたいと思った。事故の原因究明や責任の所在を明らかにするのではなく、当事者の話を積み上げていくような記事が書きたいと思った。 そして、今回ファーストサーバの全面的な協力により、事故当時から現場を統率してきた現代表取締役社長の村竹昌人氏をはじめ、営業、開発、運用、マーケティング、広報、サポート、管理など各部門の担当者に話を聞くことができた(以下、敬称略・役職は現職)。 事故から2年間の間、ファーストサーバはひたすら事故の影響を受けたユーザーへの対応と再
「当社では近い将来、オフィスビルにあるサーバールームを『ネットワークルーム』と呼ぶようになるだろう」。TOTOの名取順情報企画本部長はこう語る。「サーバーが無くなり、ネットワーク機器だけが残るようになる」(同)からだ。 TOTOは2018年までに、社内サーバーの8割をNTTコミュニケーションズ(コム)のデータセンター(DC)やクラウドへと移行する。2017年には、北九州市の小倉本社にあるサーバールームを大幅に縮小する予定だ。移行は2010年から開始している。 TOTOだけではない。ヤマハ発動機やキヤノンマーケティングジャパン(MJ)、熊谷組、ディスカウントストア「トライアル」を展開するトライアルカンパニー、電気通信工事大手のミライト・ホールディングスなどが、社内で運用してきた業務系システムを、社外のDCに全面的に移行し始めている(表1)。
スタートアップ企業等の少人数チームの場合、専任のシステム運用担当がいることは稀だと思います。本記事では、そうした少人数チームの開発兼運用担当者を主な対象として、システム運用の重要な要素である「システム稼働状況の確認、障害対応」を省力化するための方法の一つとして「システムの監視」の方法について説明します。 少人数チームでのシステム運用 Retty開発担当の鹿島です。第1回で少し紹介しましたが、RettyはWebサイト、iPhoneアプリ、Androidアプリの計3プラットフォームを、3人+αの開発者で開発を進めています。私は主にWebサイトの開発とインフラ全般を担当しているのですが、Webサイトの開発がメインのため、インフラ構築・運用に割ける時間はそれほど多くありません。 おそらく世間の小規模チームの大半では、我々と同様に専任の担当者がいないと思われます。今回の記事はそうしたスタートアップ企
プルリクエスト/レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する:Gitブランチを使いこなすgit-flow/GitHub Flow入門(終)(1/2 ページ) 数回にわたってgit-flowとGitHub Flowを使ったGitの活用テクニックを紹介します。最終回は、GitHubが採用している、git-flowよりシンプルな構成のブランチ管理フローについてです。5つの運用ルールや開発の流れを図を交えて解説します。 本連載「Gitブランチを使いこなすgit-flow/GitHub Flow入門」では、これまでgit-flowについて解説してきました。git-flowはプロダクトを厳格にリリースすることを念頭にフローが考えられていますが、プロジェクトによっては、冗長過ぎると感じることもあるかもしれません。本連載の最終回となる今回は、git-flowに比べシンプルなブ
管理を無茶振りされたサーバを守り抜け! Hardening One Remix開催:優勝は会津若松市のITエンジニア集団(1/2 ページ) 2013年7月6日と13日に分け、「守る技術」「運用する技術」を競うセキュリティイベント「Hardening One Remix」が開催された。 「え、これ、めっちゃ古いバージョン入ってない?」「SSHの設定は変えておかないとまずいよねぇ」「さっきやられたから、修正して再起動して、もし次来たときには自動的に再起動するようにしておいたよ」……2013年7月6日と13日に開催されたセキュリティイベント「Hardening One Remix」。6日の競技会場では、参加各チームでこんな緊迫したせりふが飛び交った。 Hardening One Remixは、「守る技術」「運用する技術」を競うセキュリティイベントだ。Web Application Securit
最近は僕の周りでアプリのリリースが相次いでいます。 みんなが頑張って何ヶ月も掛けて作ったアプリのリリースは嬉しいものですよね。 僕としても出来る限りのサポートをして良いゲームに育て欲しいと思っています。 そんな中である少し気づいたことがありました。 それはチームによってリリース後の雰囲気が全く違うこと。 これは以前書いた「撤退ラインを決める勇気」という記事にも書きましたが、 担当タイトルの売上によって変わってくるものですが、 リリース後なのであまり売上に大きな差分はありません。 ではなぜこのような雰囲気の違いが出てしまっているのでしょうか? それはリリースまでのスケジュールなどが大きく関わっているのではと思います。 ソーシャルゲーム業界はある意味スピード勝負ですので、 可能な限り早くリリースして他社より先行することが大きなメリットになります。 ですので経験したことある方ならわかるかと思いま
皆さんのFacebookページの成功要因は何ですか? 体制はどのようになっていますか? 先日、Facebookページ運営者白書の記事で、企業のFacebookページ運営実態について書きました。 今回は、NTTデータ経営研究所さんの調査結果を元に、企業のFacebookページ運営実態や、FBページ運営中の企業の『成功要因』『失敗要因』などをご紹介していきます。 ■目次 【1】ソーシャルメディア導入状況 Q1.ビジネスにソーシャルメディアを導入してる? Q2.(販売チャネルの種類別)ソーシャルメディア導入状況は? Q3.(保有メディアの種類別)ソーシャルメディア導入状況は? Q4.ソーシャルメディア導入の目的と、今後の利用目的は? 【2】ソーシャルメディア運用の成功/失敗要因 Q5.ソーシャルメディアの導入で目的は達成できた? Q6.運用に「成功」した理由は? Q7.ソーシャルメディアと他チャ
サーバを運用していらっしゃる方であれば、サービスの停止は死に値します。 大事な事なのでもう一度言います。 サーバを運用していらっしゃる方であれば、サービスの停止は死に値します。 サーバ管理者は皆、突然の死に備えるべきです。 そんな過酷な場面に立ち向かうサーバ管理者の皆さんの苦労を少しでも軽減する為に、apache モジュールを書きました。 mattn/mod_suddendeath - GitHub 突然の死! https://github.com/mattn/mod_suddendeath まずコンパイルしてインストールします。 apxs -ci mod_suddendeath.c -lhttpd -lapr-1 そして apache を再起動します。 サービスが動作しているディレクトリの .htaccess に以下を書き込みます。 SetHandler suddendeath すると
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model(上記は翻訳記事)を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
[対象: 全員] ファッションブランドのバーバリー (Burberry)の米国向けサイトがGoogleのインデックス(検索結果表示)から消滅してしまいました。 同時に、ツールバーのPageRankが5から0になりウェブマスターツールには検索結果でのクリックが著しく減少したことを通知するメッセージが届いていました。 原因は重複コンテンツです。 サイト管理者が公式ヘルプフォーラムで助けを求めたところ、Google社員のJohn Mueller(ジョン・ミューラー)氏によって理由が判明しました。 バーバリーは、40以上の国に対して専用のサイトをサブドメインで分けて運用しているそうです。 米国向けには us.burberry.com.、英国向けには uk.burberry.com、カナダ向けには ca.burberry.com といった具合です。 いくつかのサイトでは使用している言語が英語で、通貨
へんじがない。ただのポンコツのようだ。 ポンコツが今日も持ち場でガンバリつつ、 楽しく生きていくための備忘録ブログ。ぬわーーっっ!!2005年7月から絶賛「更新」中! 【この記事の所要時間 : 約 5 分】 フロントエンドのパフォーマンスチューニングで、やっぱり気になるのが、gzip圧縮をして転送量を減らすこと。圧縮していないので、以下のように YSlow では、F という最低のステータスになっていた。 F 4. Gzip components これではいけないと、gzip圧縮について調査してみることにした。 mod_deflateを利用してHTTPレスポンスをgzip圧縮 Apache2.0, 2.2系統ならmod_deflateを利用することでレスポンスの圧縮が可能です。ちなみにApache2.2系からはmod_filterがどうも推奨されているようなのですが、まとまった情報が少なかっ
大人気ソーシャルアプリ「ドラコレ」のインフラ 最初に紹介するセッションは「大ヒットソーシャルアプリ「ドラゴンコレクション」の裏側 ~ 超高トラフィックを支えるアプリ・インフラの“明日から使えるテクニック”」。講演者は、コナミデジタルエンタテインメント ドラコレスタジオ マネージャー 廣田竜平氏だ。 「ドラゴンコレクション」(以下、ドラコレ)はコナミデジタルエンタテインメントが製作・運営しているソーシャルゲームである。同社の廣田氏による講演では、ドラコレを運用するインフラ技術について紹介された。 廣田氏によれば、ドラコレのHTTPリクエストはピーク時で1秒間に5けた台にのぼり、それを3けたの台数のサーバによって運用しているという。サーバ技術自体はCentOS+Apache+PHP+MySQL(+memcached)という一般的なLAMP環境であり、複数のソフトウェアロードバランサとDNSラウ
ほとんどのシステム管理者が経験したことがあるはずの状況は「何か悪いことが起きていて、サーバがダウンしているが、しかし何が起きているのか分からない」というシチュエーション。サーバを管理するシステムアドミニストレーターなどの立場でいると何が大変かというと、実際の製品として動かしている実環境でこのような問題が発生した場合です。 そこで役に立つのがこのオープンソースソフト「Trouble-Maker」です。 Trouble-Maker http://trouble-maker.sourceforge.net/ システム管理者の仕事を簡単にするため、多くのツールが存在していますが、未知の状況を経験している場合になんとかしてくれるわけではありません。この一連のソフトウェア群「Trouble-Maker」は既存の便利なツールとは異なり、問題を解決するのではなく、むしろ問題を引き起こします。インストールし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く