新型コロナウイルスの重症患者が急増している。特に40代・50代の重症化が目立つのが第5波の特徴で、東京都では重症患者の6割を占める。だが、この年代へのワクチン接種の進み具合は、自治体によってばらつきが大きく、かなり遅れている所も多い。そんな中、東京都墨田区では、今月7日時点で1回の接種を終えた40代は区民の6割を超え、50代は7割近くに達している。 今月13日付日経新聞電子版によると、同紙が緊急事態宣言下にある6都道府県の主要都市の1回目接種率を調べたところ、墨田区は50歳代で71.9%、40歳代で60.6%とダントツに高かった。40代については、さいたま市(6.7%)、那覇市(16.4%)、大阪市(17.7%)、世田谷区や品川区(17.8%)などと接種率が伸び悩む自治体が少なくない中、墨田区の進捗状況は際立っている。その効果か、陽性者数の推移を示すグラフからは、陽性者が下降の兆しも見てと

Different versions of your site can be running at the same timeIt's pretty easy for a user to be running an old version of your site. Not only that, but a user could be running many different versions of your site at the same time, in different tabs, and that's kinda terrifying. For instance: A user opens your site. You deploy an update. The user opens one of your links in a new tab. You deploy a
黒枠のラベルは、コンテンツホルダー自身が付与したものです。グレー枠のラベルは本文解析で自動付与されたものです。 【ニューヨーク共同】米グーグルは24日、傘下の動画サイト、ユーチューブについて、世界で配信する動画の画質を一時的に引き下げる方針を明らかにした。新型コロナウイルス対策の外出制限が広がり、サービスの利用が増えており、インターネットが停滞するのを防ぐ。グーグルの広報担当者は「システムへの負荷を最小限に抑えるために、役割を果たす」と説明。初期設定を容量が小さい画質にする。期間は1カ月程度の見通し。手動で高画質に切り替えることはできるという。 動画配信を巡り、欧州連合(EU)がIT大手各社に対し、容量の大きな高解像度(HD)の映像を減らすよう要請していた。

この記事は本番環境でやらかしちゃった人のアドベントカレンダー14日目の記事です。 多少フェイクを入れているので整合性のおかしい部分があってもご了承ください。 https://qiita.com/advent-calendar/2019/yarakashi-production 背景 モバイル版だけでMAUxx万人のそこそこ規模の大きいサービス。Android/iOS/Webの3プラットフォームで提供。 開発元が撤退済みで、運営元から協力を依頼されとりあえずWeb以外の面倒を見ることに。2社にバラバラに開発を頼んでいたようで、なぜか変なところでAWS環境が2つに別れている。 色々と設計が荒く、ドキュメントもないのでアプリの追加開発の片手間でアーキテクチャの全容把握と改善計画を練っている途中の状況 新規登録時の確認メール、パスワード再発行メールでAWSSESを利用(メール利用はそれだけと認識
![[AWS] Amazon SESのアカウントが止められちゃった話 - Qiita](/image.pl?url=https%3a%2f%2fcdn-ak-scissors.b.st-hatena.com%2fimage%2fsquare%2f4f08a7aac8188f258759458f1fc1b2ef038cd9d3%2fheight%3d288%3bversion%3d1%3bwidth%3d512%2fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fqiita-user-contents.imgix.net%25252Fhttps%2525253A%2525252F%2525252Fcdn.qiita.com%2525252Fassets%2525252Fpublic%2525252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%25253Fixlib%25253Drb-4.0.0%252526w%25253D1200%252526blend64%25253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFwLW5vcnRoZWFzdC0xLmFtYXpvbmF3cy5jb20lMkYwJTJGNDc1MTMlMkZwcm9maWxlLWltYWdlcyUyRjE1Nzk5MjE2Njc_aXhsaWI9cmItNC4wLjAmYXI9MSUzQTEmZml0PWNyb3AmbWFzaz1lbGxpcHNlJmJnPUZGRkZGRiZmbT1wbmczMiZzPWFhZWU1ZmI2ZDg1NzE1MTQ1MDdhZDNkODFjODdmNWVj%252526blend-x%25253D120%252526blend-y%25253D467%252526blend-w%25253D82%252526blend-h%25253D82%252526blend-mode%25253Dnormal%252526s%25253D5d7c1dbef92f42a043c0e580166c567f%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526fm%253Djpg%2526mark64%253DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCQVdTJTVEJTIwQW1hem9uJTIwU0VTJUUzJTgxJUFFJUUzJTgyJUEyJUUzJTgyJUFCJUUzJTgyJUE2JUUzJTgzJUIzJUUzJTgzJTg4JUUzJTgxJThDJUU2JUFEJUEyJUUzJTgyJTgxJUUzJTgyJTg5JUUzJTgyJThDJUUzJTgxJUExJUUzJTgyJTgzJUUzJTgxJUEzJUUzJTgxJTlGJUU4JUE5JUIxJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMzQTNDM0MmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LXBhZD0wJnM9YjU5ZTdiNjFlYzg5ZWY2MDM0YTAwZWZmMzM3YjFlNjc%2526mark-x%253D120%2526mark-y%253D112%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDB1bmRvcm9pZCZ0eHQtY29sb3I9JTIzM0EzQzNDJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1wYWQ9MCZzPWNlNmEyODZhYzcyZjdiMzdmZjY3ODcwOTc0MzNkOTE4%2526blend-x%253D242%2526blend-y%253D480%2526blend-w%253D838%2526blend-h%253D46%2526blend-fit%253Dcrop%2526blend-crop%253Dleft%25252Cbottom%2526blend-mode%253Dnormal%2526s%253D5cd380ca8576dd805d1fb78ea5246e08&f=jpg&w=240)
こちらが何を聞いても、一事が万事この調子です。その後、スケジュールに押し切られる形でシステムはリリースされ、現場は火の海となりました。 鳴りやまない監視アラーム…… 対処方法のわからない障害…… 使い道のわからない体裁だけ整った手順書の数々…… 右往左往する運用メンバーと構築メンバー…… 結局、運用が安定するまで半年以上の期間がかかりました。 その頃は「運用設計」という言葉も概念もまだ浸透しておらず、残業によるマンパワーで運用を安定稼働させるしか術はありませんでした。 (この時にこの本があったら、どれだけ指標になったかと今なら思います)。 運用を取り入れた設計構築へのチャレンジ この経験から、運用が大変な理由の諸悪の根源はシステムリリース時にあると考え始めました。いま思えば、初めに入った楽園のような現場は、目的のはっきりした手順書しかなく、トラブル時の連絡先も明確でした。“楽園システ

「システム障害アラート、やっぱり電話で発信したいよね…」 システム運用の要である障害アラート。異常発生に即対応するためのアラート運用は重要です。アラートの通知先としては代表的なものにメールがありますし、最近ではSlackなどのチャットツールを併用している現場も多いと思います。 しかし、やっぱり昔から一番緊急度が高いアラートとして利用されているのは、「電話」じゃないでしょうか。そう、聞きたくないんだけれど聞かないといけないアレです。 ただ、電話によるアラートをシステムに組み込むのって敷居が高そうじゃありませんか?サードパーティーのサービスを契約したり初期費用がかかったり時間も手間もかかったり… そこでAmazon Connectの出番ですよ。 実際やってみましたが、月4USD程度のランニングコストと1時間程度の手間で、手軽にSNS経由で電話発信する仕組みを作ることができました。Amazon

sshやmoshでリモートサーバに接続する際に、tmuxのwindowを自動で生成しており、 リモートサーバに接続とtmuxがセットになっているので、tmuxを使ってリモートサーバでの作業ログをローカルに保存出来ないかと思って調べていたら pipe-paneを利用すると可能ぽいのでやってみた。 利用環境はtmux 1.7です。(OSはMountain Lion、SL6.1、CentOS6.3全てで動作しました。) ログ用ディレクトリを用意 pipe-paneを利用する前にログ用ディレクトリを作っておく。 prefix key + Hでロギング開始 prefix key + hでロギング終了 という感じです。 そうすると~/.tmux/tmux-hogemoge.logみたいなログが出来上がる。 hogemogeの部分はtmuxのwindow名が入ります。tmuxのバージョンが古いと tmu
ssmjp 2019/07での発表資料です。アウトプット枠でのブログに対するアンサーセッションをやりました。 同じように止まってしまう人がほとんどだろうなぁと思ったので良い機会となりました。 ありがとうございます。 (運用設計ラボ合同会社 波田野裕一)

SpotifyがミスによりKubernetesの本番クラスタを二度も削除。しかし顧客へのサービスにほとんど影響しなかったのはなぜか? 今年、2019年5月20日から3日間にわたりスペイン バルセロナで開催されたKubeCon+CloudNativeConEurope 2019の基調講演では、SpotifyがミスによってKubernetesのクラスタを消去してしまった経験を振り返るという非常に興味深いセッション「Keynote: How Spotify Accidentally Deleted Allits Kube Clusters with No User Impact - David Xia」(基調講演:SpotifyはいかにしてKubernetesクラスタの全削除というミスにもかかわらず顧客への影響を引き起こさなかったのか?)が行われました。 障害が起こることをあらかじめ計画とし

こんにちは。そろそろプロ野球シーズンの開幕が待ちきれなくなってきたコネクト支援チーム*1の酒井(@sakay_y)です。 サイボウズでは、新入社員全体研修の後に、開発系の新入社員に対して1ヶ月程度の開発研修をおこなっています*2。内容は、毎年改善を重ねていますが、基本的には講義+実習です。本記事では、先日公開した2018年の研修の講義資料を、全体の流れに沿って紹介したいと思います。 開発・運用研修について本研修は「開発本部・運用本部に配属される新入社員が、部署配属後に必要となる基礎的な知識/技術/ツールを学び、体験できる。」ことを目的にしています。 新入社員3〜4名を1チームとして、そこに担当のメンターが1名付いて研修を進めていきました。講義では先輩社員に講師をお願いし、開発演習では各チームにメンターとは別の先輩社員が担当スクラムマスター(!)として付きました。 スケジュール 7/2 〜
俺の愛用ワンライナー、Web企業のエンジニア16人に聞きましたエンジニアの皆さんが愛用する自作のワンライナーってどんなもの?Web企業で働くエンジニアの方々に、秘蔵のワンライナーを聞きました。 ワンライナーとは、何か特定の処理を「たった1行のプログラム」だけで実現するものです。サービス運用に携わるエンジニアの皆さんも、愛用している独自のワンライナーを持っているのではないでしょうか。「独自のワンライナー」とは、エンジニア各人のナレッジやノウハウが詰まっているとも考えられます。本企画ではさまざまジャンルで活躍するエンジニア16人に、業務を支えてくれるワンライナーを紹介してもらいました。参考に使ってみるも良し。眺めて楽しむも良し。個性あふれる貴重な「オレオレ・ワンライナー」の数々をご覧ください! ※各カテゴリー内では所属企業名の50音順に掲載。回答者は敬称略とする。 リソース管理 プロセスを

このガイドラインについて こちらのガイドラインは社内のバッチ処理スクリプト開発にあたっての、安定運用等に関わるガイドラインを公開用に書きなおしたものになります。 バッチサーバ規則 基礎項目 以下の要項を満たすことを確認する その他の用途で動作しているサーバ上での動作は行っていないこと 運用期間中に想定しうるデータ量にてOOMキラーに殺されないこと 想定の時間で終了すること データの読み込みは極力Read Replicaを見ていること データの書き込みによる本番サーバへの影響が見積もれていること 冪等性が担保されており、何度実行しても処理上の不具合は発生しないこと 多重実行時に不整合が発生しないこと エラー時の社内への通知が用意されていること エラー時の通知には再処理のための手順が揃っていること、もしくはそのドキュメントの場所が示されていること 個人ユーザー下にログや成果物を絶対に書き込んで
![[公開版]社内バッチ処理ガイドライン - Qiita](/image.pl?url=https%3a%2f%2fcdn-ak-scissors.b.st-hatena.com%2fimage%2fsquare%2f2f47943ce62163bba4a70f69209153a67e1bb401%2fheight%3d288%3bversion%3d1%3bwidth%3d512%2fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526mark64%253DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU1JTg1JUFDJUU5JTk2JThCJUU3JTg5JTg4JTVEJUU3JUE0JUJFJUU1JTg2JTg1JUUzJTgzJTkwJUUzJTgzJTgzJUUzJTgzJTgxJUU1JTg3JUE2JUU3JTkwJTg2JUUzJTgyJUFDJUUzJTgyJUE0JUUzJTgzJTg5JUUzJTgzJUE5JUUzJTgyJUE0JUUzJTgzJUIzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMzQTNDM0MmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz03OTYzZTg3NWNmMjI1MTEzNWZlMDVjNTBkZmJlMDM3Nw%2526mark-x%253D120%2526mark-y%253D96%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9OTcyJnR4dD0lNDB5X21hdHN1d2l0dGVyJnR4dC1jb2xvcj0lMjMzQTNDM0MmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz04NzdkNTI0MmY3MGI5ZWZjZmY5NTkxMzFiOGQ1MjU3NQ%2526blend-x%253D120%2526blend-y%253D445%2526blend-mode%253Dnormal%2526txt64%253DaW4gRE1NLmNvbQ%2526txt-width%253D972%2526txt-clip%253Dend%25252Cellipsis%2526txt-color%253D%2525233A3C3C%2526txt-font%253DHiragino%252520Sans%252520W6%2526txt-size%253D36%2526txt-x%253D134%2526txt-y%253D546%2526s%253D8c79681077a0d87b1682bcc91012884b&f=jpg&w=240)
(タイトルは釣りです) いい加減、>/dev/null 2>&1と書くのをやめたらどうか - DQNEO起業日記 この記事のタイトルがtwitter で流れてきたのを見て、「そうだ!出力を /dev/null に捨てるなんてとんでもないよね!」と思ってよく読んだら /dev/null に間違いなく捨てる方法だったのでついcrontabに > /dev/null 書いたら椅子投げる 2012-06-13 00:01:17 via YoruFukurou とつぶやいてしまったのですが、では出力を捨てないためにはどうすればいいのか。現時点での個人的ベストプラクティスを書き留めておきます。 デフォルト : メールで送る (MAILTO) せっかくcron daemon がログを捨てないためにわざわざメールで送ってくれるのに、それを > /dev/null で踏みにじるとはひどい。 とはいえ、
いつ起こるかわからない“一瞬”のために働くということ~Yahoo!ニュース運用エンジニアのジレンマと醍醐味【ニュース×働く】Yahoo!ニュースの中の人やニュースに関わる人などの声を通じて「“ニュース”とともに働くということ」について探る【ニュース×働く】、第3回目のテーマは「運用エンジニアの頭の中」。 普段当たり前のように表示されているウェブサイトですが、「いつもと変わらない日常」の裏には運用エンジニアの存在が欠かせません。今回は、普段なかなか表に出る機会の少ない、Yahoo!ニュースの“縁の下の力持ち”ともいえる運用エンジニアチームのスタッフに話を聞きました。(聞き手/Yahoo!ニュース編集担当・井上芙優) 【ニュース×働く】過去の記事 ・[兼務]「記者・編集者はつぶしがきかない」は取り越し苦労? ・[時短勤務]24時間体制の職場での時短勤務は「申し訳ない」ことなの? 仲辻正幸(な

Rundeck by PagerDuty Trusted by thousands of organizations. Enhance operations with scaled orchestration and self-service. Built on Open Source Rundeck is the orchestration tool for all of your existing automation, reducing operational overhead and improving team efficiency. Organizations can minimize downtime, enhance productivity, and drive business agility. →Job scheduling and infrastructure ma
1ヶ月くらい前、 「バグをドラゴンと呼んだらどうなるか」というTweetを見ました。 確かに、バグをドラゴンと読んだ場合「Sクラスのドラゴンが出ました!」「Aクラスのドラゴンを相手にしてる最中だってのに!」って会話になるし、ドラゴンは結局人の手で生み出されたものってところが中二ファンタジーっぽくて良い— 尾野(しっぽ) (@tail_y) March 18, 2015 これは天才的発想だなと思って職場で雑談で話してみたところ、 同僚のスペイン人エンジニアにバカウケしまして、 それからちょいちょいバグのことをドラゴンと呼ぶようになりました。 せっかくなので、どんな雰囲気になるのかまとめてみようと思います。 先に言っておくと、自分ともう1人スペイン人エンジニアが時々チャット上で使っているだけで、 正直そんなに流行ってないです。 なんかテンションが上がる バグ修正ってマイナスをゼロにするだけで何

はじめに このエントリは非常にポジティブで技術的なチャレンジに関するまとめであり求人エントリでもあります。 まとめ 昨年後半から、急成長するサービスを支えるため “どオンプレ” な環境で作ったサービスをクラウドに持っていく仕事をしていました。 クラウドのオイシイところを押さえられるよう作り変えをした結果として “Infrastructure as Code” を実践することになり、結果としてソフトウェアエンジニアだけですべてがコントロール出来る状態になり、インフラおじさん業が不要になりました。 そういった環境で働きたい "腕の立つITエンジニア(特にスマホとサーバサイド)" を募集しています。 発表資料&箇条書きで振り返る最近の動きAWS Casual Talks #3 https://github.com/myfinder/aws-casual-3/blob/master/slide.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く