JAWS-UG Osaka 第13回勉強会 「オペレーションじょうず」(https://jawsugosaka.doorkeeper.jp/events/22064) で発表した「クラウドの運用になって インフラエンジニアは何が変わるのか?」の公開資料です。Read less
![2015-05-23 クラウドの運用になって インフラエンジニアは何が変わるのか?](https://cdn-ak-scissors.b.st-hatena.com/image/square/7726f3d148bafa153eac6731d0c1013e232472f6/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F20150523-jaws-ug-osaka-150523070603-lva1-app6891-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
管理者の重要な仕事のひとつに、テストがあります。新しいシステムのテスト、H/W、 OSやソフトウェアなどの移行にともなうテスト、過去に発生したミスの再発防止テストなどいろいろなテストありますが、目的はシステムが要件通りに稼働し続けることの保証です。今回は、テストの自動化を取り上げます。 テストの自動化 安定したシステムにテストは欠かせませんが、みなさんの環境ではどのようにテストをしているでしょうか。手順がExcelに並べられているだけだったりしませんか。ミスが起きたら、再度同じミスをしないためのテストをしていますか。ミスが起きない、もしくはミスがあってもできるだけ迅速に検知できることをテストで保証できているでしょうか。 以前ファイアーウォールの移行作業をしたのですが、製品のベンダが異なるためACLの記法も異なり、設計思想も異なっていため、簡単にはACLを移行することができませんでした。AC
前回の(1)はこちらから。 プロジェクトでcronを利用する 筆者は普段ゲーム開発のサーバサイドを担当していますが、プロジェクトによってはバッチサーバのcrontabが100行を超えることもあります。イベント、ランキング処理、監視、集計、バックアップ、リカバリ処理などをしっかりやろうとすると、どうしてもそれくらいになってしまいます。 100行とはいかなくても、プロジェクトで使うcrontabの行数が膨らんでくると、サーバで直接crontabを編集することは管理上現実的ではありません。 crontabの記述とリポジトリ管理 では実際のプロジェクトでcrontabをどのように管理していけばよいのでしょうか。筆者は次の方針を立てています。 crontabの記述にゆるやかな規約を設け、リポジトリ管理する crontabの自動テストを行う crontabの反映方法をなるべく自動化する crontab
カーネルの I/O Accounting 機能を利用する Linuxでカーネルのバージョンが 2.6.20 以降であれば、IO Accounting機能を使うとよい。 これが有効になっていれば、プロセス毎のI/O統計情報が /proc/${pid}/io に出力される。 …が、全プロセスについて、これを自前で分析するのは疲れるので、pidstat や dstat のようなツールを使うのが楽。 参考 IO Accounting 機能で I/O 負荷の高いプロセスを特定 :: drk7jp dstatの万能感がハンパない - (ひ)メモ iodump 2.6.19 以前のカーネルではどうすればいいか。 例えば、iodump というツールがある。 これは以前 Maatkit に含まれていた Perl スクリプトである。 使い方としては、以下の通り。 # download iodump wget
はじめに 本ブログでは、Chefおよび、Vagrantを用いた仮想インフラの構築について取り上げてきました。今回は、構築した仮想インフラの障害監視を行う監視システムの構築方法を2回に分けて解説します。第1回は、サーバー監視ツールのNagiosのインストールから、監視対象サーバの設定方法を解説します。 なお、構築に必要なソフトウエアは、Chefを用いたLAMP開発環境の構築方法~仮想環境構築編を参考にして、インストールして下さい。また、全ての構築作業は、Chefを用いて行います。 監視サーバの構築 構築する監視サーバのベースとなる仮想マシンを作成し、HTTPサーバをインストールします。 Boxの初期化 ベースとなる仮想マシン(Box)の初期化を行います。 $ mkdir -p ~/vagrant/nagios-server && cd ~/vagrant/nagios-server $ va
それほどDBに詳しくないアプリエンジニアが何かトラブった時にすぐさま行動して問題把握できるようになる情報を列挙しておきます。 開発時、障害時の対処療法やちょっとした定期監視方法などを対象にしています。 抜本的な対策などはインフラエンジニアさんにお任せしたほうがいいと思います。 DBはいろんな意味でこわいんでできれば触りたくないです>< 事前確認 MySQLサーバーのシステム設定値を確認しておく 以下のようにサーバーのシステム設定値を確認できます。 mysql> SHOW GLOBAL VARIABLES; # ワイルドカード(%)を用いた絞り込み mysql> SHOW GLOBAL VARIABLES LIKE 'performance_schema%'
「あんたの言う通りかもしれんな。IT部門はシステム子会社も含め一度解体再編したほうがよいだろうね」。最近会った大手製造業の元CIO(最高情報責任者)はそう言った。私のコラム「極言暴論」の記事を巡って議論したときのことだ。この人は当初「あんた、酷い記事を書いているな」と文句を言っていたが、本音ベースの話になると私と全くの同意見だった。 私は、一部の企業を除けばIT部門には将来が無いと思っている。今や多くのIT部門が、ビジネスのイノベーションにITを活用したいという事業部門や経営の要望に背を向け、基幹系システムという名の“間接業務支援システム”のお守りに汲々とする存在に成り下がっているからだ。だから私は、IT部門の解体再編の必要性を主張している(関連記事:寿命が尽きるIT部門に「終活」のススメ)。 こうした極言暴論の記事が多くのIT部門関係者の目にとまったようで、「一度話をしたい」と彼らから呼
スタートアップ企業等の少人数チームの場合、専任のシステム運用担当がいることは稀だと思います。本記事では、そうした少人数チームの開発兼運用担当者を主な対象として、システム運用の重要な要素である「システム稼働状況の確認、障害対応」を省力化するための方法の一つとして「システムの監視」の方法について説明します。 少人数チームでのシステム運用 Retty開発担当の鹿島です。第1回で少し紹介しましたが、RettyはWebサイト、iPhoneアプリ、Androidアプリの計3プラットフォームを、3人+αの開発者で開発を進めています。私は主にWebサイトの開発とインフラ全般を担当しているのですが、Webサイトの開発がメインのため、インフラ構築・運用に割ける時間はそれほど多くありません。 おそらく世間の小規模チームの大半では、我々と同様に専任の担当者がいないと思われます。今回の記事はそうしたスタートアップ企
あまりにも親切なコメントが多いので、先頭にも書いておきます。 1.そもそも!Macの上に!VMで!Windowsたててますから! 2.開発&本番がWindowsのPHP必須の要件じゃなきゃ!そもそも!俺だって!Windows使う気ないから!! お願い この寒くて無知な記事を全ディスして解決策を提示しちゃうするエントリかいたら絶対にブクマのびますよ!!リンクもはらせて頂きます!チャンスだから是非書いてください!!(懇願 追記:回答をいただきました ・ http://blog.textt.net/nyontan/6 ホワイト案件お待ちしています ・ https://gist.github.com/matarillo/6208533 Web PIと WebMatrix はつかったことがないので是非使ってみたいですね、助かる命が有りそうです。しかしApache必須の命は救われない奴だ…。 ・ ht
Twitterの大規模システム運用技術、あるいはクジラの腹の中(前編)~ログの科学的な分析と、Twitterの「ダークモード」 先週の6月22日から、米サンタクララで行われていたWebサイトのパフォーマンスと運用に関するオライリーのイベント「Velocity 2010」が開催されていました。 その中で、TwitterのJohn Adams氏がTwitterのシステム運用について説明するセッション「In the Belly of the Whale: Operations at Twitter」(クジラの腹の中:Twitterでの運用)が行われています。Twitterのような大規模かつリアルタイムなWebサイトの運用とはどういうものなのでしょうか? 公開されているセッションの内容を基に概要を記事で紹介しましょう。システム管理者の新たな役割、Railsの性能の評価、Bittorrentを使った
えらいことなってますが。 正規手順と今回の現象の説明などを含めた中間報告が出されています。 http://support.fsv.jp/info/nw20120625_01.html ここで、正規手順で、途中でオペレーションミスがあったときに復旧できない状態になってしまう可能性があることがわかります。 具体的には「原因3:メンテナンス仕様」のこの部分。 脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用する この時点でこの更新プログラムに不具合があった場合には、リストアできなくなることになるわけです。そして今回はそれがおきたようです。 より安全な手順であれば、バックアップ側にパッチをあてている間は正常系がバックアップのバックアップということになるはず*1ですが、どこにもバックアップがない状態になってしまったわけです。 手順1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く