「なんで夏休みの宿題やっていないの！？」への私の答えは「意義が感じられず、習慣がなく、上手くできず、他のことが魅力的だから」 - 斗比主閲子の姑日記
なぜか昨日だけで２つも、『詰問のなぜ』を扱ったTwitterのまとめが話題になっていました。 「なんで？」と聞くと“責められている”と感じて言い訳したり嘘をついたりetc.してしまう人にはこう返すと良いかもしれない - Togetter 「なんで宿題やってないの？」理由を聞きたい？宿題をやらせたい？ - Togetter なんででしょうね。大人がお盆休みが終わり仕事が始まってストレスを感じているのか、子どもが夏休みももう終わるのに夏休みの宿題が終わっていないことに親が苛立っているから、とかかな。 いずれにせよ、以前から何度も書いている通り、「なぜ？」は自分に問うのは別として、他人に問うのは大体ポジティブな結果をもたらさないので、相手を追い詰めたり、自分への悪印象を抱かせたいという目的がない限りは、私はお勧めはしません。 ここからは私個人の話です。 私は子どもの頃に「なんで○○してないの！？
8月23日のAWSの大規模障害でMultiAZでもALB（ELB）が特定条件で500エラーを返すことがあったという話 - Make組ブログ
このブログ記事で 「MultiAZ」にしていたら何事も全て大丈夫という認識を変えられると嬉しいです （当該の時点で障害起こした人はちゃんとMultiAZにしてなかったんでしょ？という人の認識も変えられると嬉しいです）。 MultiAZにしておくことは基本 です。 その上でも、 安心しきらずに監視は必要 という話をしています。 MultiAZ構成にしておきましょう そのうえで監視、検知、トレーサビリティを大切にしましょう MultiAZ要らないという見当外れの解釈はしないでください （一部、間違えた解釈をしてるコメントも見受けられましたが、大いに違います）。 前提 2019-08-23、AWSで大規模な障害が起こりました。 障害の一般的な内容は以下のとおりです。 まとめのブログ https://piyolog.hatenadiary.jp/entry/2019/08/23/174801 AW
Sidekiq のワーカーノードをオートスケールさせてEC2の稼働コストを60%削減させるまで - Qiita
このストーリーの登場人物は以下の2人です。 依頼人 = アプリケーションエンジニア or マネジメント層（適宜文脈によって読み替えてください） 匠 = インフラエンジニア Before まずは依頼人が抱えるお悩みについて話を聞いてみることにします。 インフラ構成 依頼人のサーバ構成は、 Sidekiq では標準的な構成を採用していました（図1, 2）。 Web ノードでタスクを Redis 登録し、 Worker ノードで Redis からタスクを取り出し実行します。 Web ノードは API として外部に公開されているほか、 Sidekiq の GUI として利用しています。 各ノードは AutoScalingGroup を構成していますが、台数固定で稼働しています。 図1. サービス構成: 図2. AWS構成図: 以下の文章では、便宜的に以下の用語を用います: マスターノード: タスク
障害から学ぶクラウドの正しい歩き方について考える - そーだいなるらくがき帳
AWSで大きな障害が発生したこの機会に、自分がクラウドと正しく付き合っていくために必要なことを考える。 piyolog.hatenadiary.jp ちなみに稼働率 99.99% くらいを目指していくために必要な事を考える。 必要な稼働率を見極める 今回は 99.99% くらいを目指すと言ったが、実際に自分たちにとってどのくらいの稼働率を目指すか？ということはとてもとても大切だ。 幸い、今回自分は影響がなかったが、本当に完璧か？と言われるとそうではない。 まず弊社の場合、マルチリージョンではないので東京リージョンが落ちたら落ちる。 これを許容できない場合に99.99%を目指せるか？というと正直厳しい。 しかしサイトの規模はそんなに大きくないのでデータサイズも現実的に転送出来る範囲で、コンポーネントも少なく、TerraformやAnsibleによって再構築しやすい状態は整っている。 そのため
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS障害で本当に知っておくべきことと考慮すべきこと
クラウド集中にもろさ アマゾン「AWS」大規模障害 - 日本経済新聞