トラブル☆しゅーたーず

解答編

ハッシュタグ：#トラしゅ

おつかれさまでした！

ビールがうまいね！

運営からのお願い

資料を公開して、URLをつぶやいてください

ハッシュタグは #トラしゅ で！

正しい状態

なんせサイトが動いてればokということでした

1. トップページが表示できる

2. 個別記事が表示できる

3. お問い合わせできる

ができていればok♡

さて？

　山○君は何をしてしまったんでしょうか？

​

　対象サーバにつながらなかったですよね？

　sshはつながらない、そういう設定でした

　セキュリティを気にするお客さんって言ったでしょ？

​

　彼は、実はコンソールから作業をしていたんです。

　だって「どうやってつなぐか？」

　なんてどこにも書いてないんだもん

解答編

• 山○君は何をしてしまったのか？

　　前任者は効率化の為に、いろいろやっていたみたいです。

　　だから、メンテナンス用にちゃんと　ShellScriptは用意されていたんです。

　　※　本当にあったんですよ。

　　でも、そんな事は手順書には反映されずにかれは、手作業でメンテナンス

　　したんです。

山◯くんが実施した作業

rootユーザで実施

# cd

# /etc/init.d/mysql stop

# mkdir bak

# cp /usr/local/mysql/data/mysql-bin.* bak/.

# mysqldump -u root -pdbadmin123 --all-databases \

--default-character-set=binary >bak/dump.sql

# mysql -u root -pdbadmin123 <bak/dump.sql

# cp -a bak/mysql-bin.* /usr/local/mysql/data/.

# service mysqld start

復旧例

1. 80/TCPをListenしているプロセスを確認
2. DocumentRootを確認
3. wp-configを確認
4. 3306/TCPをListenしているプロセスを確認→ない
5. MySQLを起動→/etc/init.d/配下に怪しいファイル�→mysql, mysqld, mysql.bak。・・・.bak！？
6. diffを見る→datadirいじってる。どちらかが正解。
7. ibdata1のtimestamp確認→新しいのは/usr/local/mysql
8. datadirを/usr/local/mysqlにして起動→成功
9. 画面表示→成功。もし変だったら考えられるのはcache
10. apache, wp, dbのcacheを確認→wpのcacheをクリアして完了

解答編

　【直接的な問題】

• 山◯くんの作業対象のDBはあっていたが、�操作対象のデーモンを間違えた
• 山◯くんの作業時に操作を誤りアクセス権限が�書き換えられてしまった(ただし関係無いほうのMySQL)
• 山◯くんに任せっきり

​

• 前任者がdatadirをコッソリ変更していた
• 構築当初、datadirの指定が変だった(どうみても設定誤り)

間接的な問題

• 前任者に任せっきりで、コソコソできた
• 具体的な手順がない
• 運用シェルがあることが山◯くんに伝わっていない→手動で実行して間違えた
• テスト環境が同居していて、構成が複雑
• 不要なデーモンやソフトがたくさん起動している

切り分けのポイント

• メンテ前までは動いていたので、メンテでの作業がトリガーなのは確実
• ただし山◯くんが原因を作ったかは不明
• とにかく頭からデータフローを追う
• どのポートに繋がってどのプロセスが処理してどこにデータを回して…
• 「やったこと」が「意図通りできている」ことを確認する
• どのプロセスに接続した？本当につながってる？

​

切り分けのポイント

そのへん書いておいたよ(∩´∀｀)∩

障害対応のポイント

• 否が応でも心拍が早くなるので、心拍が早くなっていることを確認して自覚する
• 「冷静に」を心がける。心がけても冷静でいられないから、余計に心がける
• 呼吸、口調、タイプスピードを意図的にスピードダウンする。深呼吸気味に。少し目を瞑る。ただし、寝落ちないように。その後は少し大きめに開く（クワッ
• 基本に忠実に対応し、勘に頼らない。状況を必ず確認する（動作は正常で、システムメッセージだけ間違いなどのケースもある）
• ロジックで自分を固めすぎない。自分の無知（ロジックにおける前提知識の足りなさ）を自覚する。再起動してみるで解決することは意外と多い。
• 自分を過信しない。切り替えを早くし、誰かに聞いた方が早ければ聞く。GoogleでもTwitterでも先輩でも後輩でも、問題解決のためには何でも誰でも使う

障害対応のポイント

そのへん書いておいたよ(∩´∀｀)∩

以上をふまえて

以下の内容が含まれていると、良いのではないでしょうか？

　ごめんなさいの部分

　　手動での作業を改め、エラーが無いようにする旨

　　コレを持って効率化をはかる

　環境改善

　　検証用サイトの削除

　ご提案

　　検証機の分割、具体的な手順の整備

報告のポイント

• サービス(サイト表示)影響範囲
• サービス影響時間
• 事象の概要
• 対応の概要
• 原因(不明の場合は不明と記載)
• 暫定対応(不要なら不要と記載、検討中なら検討中と記載)
• 根本対応(不要なら不要と記載、検討中なら検討中と記載)
• 効果がある対応を！
• 実現性のある対応を！
• 改善・再発防止を越える提案があるともっと◎

その他、気づいたこと

• 解決できないときは回避！

​

• 「ユーザ影響」が大事！
• 影響範囲でアクセス数とかもあるといいですね
• 影響時刻も大事

​

• 提案部分の数が多くてツラツラとしてるので、もうすこしドカンとテーマをあげたほうがよいとおもいます (なんせ、わかんない人なので)

​

話す時は申し訳なさそうだけど前向きな感じで！

と、いうわけで

優勝チーム発表！

チーム #2

​

お客さんが知りたい情報がきちんと盛り込まれていた