ISUCON8 日程決定＆1名での参加枠設置します！ #isucon : ISUCON公式Blog
こんにちは、LINEの櫛井です。 前回お知らせしたように、今年はLINE株式会社主催、問題作成は面白法人カヤックさま＆株式会社ディー・エヌ・エーさま、サーバ提供はGMOインターネット株式会社さまでバッチリお届けする予定のISUCON8！今日は3つほどお知らせがございます。 ■1つめ、開催日について ・予選 9月15日(土),16日(日) ・本選 10月20日(土) を予定しています。スケジュールを空けておいてくださいませ。 ※予選は従来通りオンラインで行い、どちらかの日程でご参加いただきます ■2つめ、申込み時期について 7月開始、8月末に締め切りで準備をしています。今年も一般・学生の2つのジャンルで募集を行います。応募開始したら即お申込みいただけると大変ありがたいです。 ■3つめ、1名での参加枠設置について 競技の成り立ちにも由来しますが、ISUCONは参加して学ぶことではなく「勝つこと
DNS over HTTPSを使ってDNSレコードを外形監視 - LIVESENSE ENGINEER BLOG
こんにちは、インフラグループの水野です。 みなさん、DNSのレコードの監視を行っていますか？ DNSレコードの変更ミス等を検知することはもちろん、自分たちの運営しているサービスの名前解決がユーザ側でどのように見えているのかというのを確認することは大切です。 しかしながら、DNSレコードを外形監視してくれる監視ツールは数が少なく中々コレといったものがありません。 外部からの監視をしたいがためにパブリッククラウドに監視専用のインスタンスを建てるのももったいないです。 弊社ではメインの監視ツールとして Mackerel を利用していますが、MackerelにはURL外形監視はありますが、DNS外形監視はありません。 別途 pingdom のDNS外形監視を利用していましたが、pingdomではIPアドレスとのマッチしかできません。 IPアドレスもひとつしか登録できないため、ELBのようにIPアド
Fluentd 入門 〜運用に必要な基礎知識〜
最近業務で Fluentd を触ることが出てきて入門したんですが、最初のうちはトラブルが起きた時に何が起きているのか、どう対処したら良いのかがさっぱりわからなかったので、「Fluentd ってログの収集とかに使われるやつでしょ？」程度の知識しかなかった過去の自分に向けて「とりあえずこれぐらいは知っておけ！」と言いたい内容をまとめてみました。 トラブルが起きた時にどの処理で問題が起きているのか素早くコードを追うことができて、データの消失を最小限に抑えつつ適切に対処できるようになることを目的としています。 なお、現時点で最新版の Fluentd v0.14.21 を対象にしています。 アジェンダ Getting Started Fluentd のアーキテクチャ Processes Supervisor process Worker process Threads Input thread En
日本オラクルが今後のJavaのリリースモデルと公式バイナリについてあらためてJava Day Tokyoで説明。オラクルによる公式バイナリの無償提供はOpenJDKベース
日本オラクルが今後のJavaのリリースモデルと公式バイナリについてあらためてJava Day Tokyoで説明。オラクルによる公式バイナリの無償提供はOpenJDKベース 日本オラクルは5月18日に都内でイベント「Java Day Tokyo 2018」を開催。午後に行われたセッション「Java SE の新しいリリースモデル」で、あらためて今後のJavaのリリースモデルと配布について説明を行いました。 説明の基本的な内容は、以前の記事「来月にはJava 10が登場し、9月にはJava 11が登場予定。新しいリリースモデルを採用した今後のJava、入手方法やサポート期間はこう変わる（OpenJDKに関する追記あり） － Publickey」と変わっていません。 本記事はセッションの内容を基に、現時点でのステータスをあらためて確認するものです。 Javaは6カ月ごとのタイムベースのリリースへ
サーバーが高負荷状態になったときのプロセス一覧を自動で出力させておく - えいのうにっき
趣味でお世話をしているサーバーインスタンスのうちのひとつが、最近以下のような事象を時折起こしておりまして。 深夜に一時的に高負荷状態に陥る 朝起きてみたらそれに気づく（終息している） さすがに趣味の範疇なので、深夜に飛び起きて対応できるようなアラート通知設定はしておらず、とはいえ起きてからその理由を探ろうとするのだけど、終息したあとに見られるものといったらせいぜい以下のようなことくらい？ モニタリングツール（Mackerel）のその当時のグラフの様子 アプリケーションログを見る /var/log とかに出力されてるログを見る 今回の場合だとCPU使用率とLA（ロードアベレージ）が高騰していたことくらいしかわからずで、そのときにどういうプロセスがリソースを食ってたんだろう、みたいなことは把握することができなかった。 こんなかんじ。diskはちょっとハネてるかな...。。 対象のサーバーには
簡単だと誤解されがちな、システムの「新元号」対応 - BCN＋R
【日高彰の業界を斬る・13】 新元号の発表は、2019年5月1日の改元の半年前と言われていた時期もあったが、新聞報道によると、政府会合では改元1カ月前に発表する方針で固まったようだ。 改元に関して合わせて話題に上るのが、情報システムの改修だ。民間企業の日常業務では西暦を使うことが多いが、官公庁、金融機関、公的機関に提出する文書等では、まだまだ和暦が使われており、日々の業務で使われているシステムが新元号に正しく対応できるかは、業種を問わずあらゆる組織における関心事になっている。 「そんなこと今から簡単に準備できるじゃないか。とりあえず“？？”とでも表示されるようにしておいて、新元号が発表されたらそこだけ書き換えればいいのでは」 このように思う人は多いだろう。筆者もまさにそう考えていた。しかし、長年にわたって使い続けられているプログラムに手を入れるとなると、そう簡単な話ではないらしい。 マイク
フルリモートワークを諦めた
正社員のフルリモートワーク採用を目標としていたが諦めた。 現在、自社では週１出社それ以外は自宅からのリモートワーク社員がいる。一緒に働いて感じたことはフルリモートワークの場合はうまくやっていくことはかなり難しいだろうと感じたことだ。 自社では自社パッケージ製品を開発している。この開発には双方向のコミニュケーションがかなり必要になる。特に顔を突き合わせて話すというのがとても重要になる。さらに感覚的な話も多くなりがちだ。 実際、週１出社してる社員とはよく話をする。仕事の話、雑談。本当に色々話をする。 特に自社は社員も少なく１社員が担う範囲も多く、意思疎通がとても重要になる。これが週１出社してもらうだけで、かなり違う。ギャーギャー面と向かって話ができるというのはとても重要だと感じたのだ。 フルリモートワークになると出社は月１回とかになるだろうか、大きめの企業であればうまくタスクが分担できたりして
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
