第33回 FreeBSDセキュリティと脆弱性とアップデート | gihyo.jp
セキュリティアドバイザリやエラッタノーティスは個別に発行されるものですが、同じ日付で数のものが同時に発行される傾向があります。発行された日付で見た場合、2015年は12月14日までの間に20回を超えるアップデートタイミングがあったことになります。管理するサーバの台数や条件によって変わってきますが、年間に20回ほどのアップデートを実施するのはあまり簡単ではない手間と言えます。 2016年以降にセキュリティアドバイザリとエラッタノーティスの発行件数がどうなっていくのかはわかりませんが、発行件数が減る積極的な理由は特に見当たらないように思います。セキュリティに対するエンジニアの技量の向上やテストやデバッグ体制の整備向上などを考えると、むしろ脆弱性や問題の発見が進みしばらくは発行件数が増えるものと考えてシステム構築を設計しておいた方が、なにかと安全ではないかと思います。 アップデート方法アレコレ
【朗報】「源泉徴収票にマイナンバー記載」、平成28年以降も不要と正式決定 - Not-So-News
実務上のポイントはこちら：【様式・注意まとめ】平成28年(2016年)分から源泉徴収票は縦長 大きさもA6からA5に倍増 nots.hatenablog.com 国税庁は２日、ホームページ上で「本人へ交付する源泉徴収票や支払通知書等への個人番号の記載は必要ありません！」とする文書を公表。 平成27年10月２日に所得税法施行規則等の改正が行われ、行政手続における特定の個人を識別するための番号法施行後の平成28年１月以降も、給与などの支払を受ける方に交付する源泉徴収票などへの個人番号の記載は行わないこととされたと説明している。 平成27年10月２日に所得税法施行規則等の改正が行われ、給与などの支払を受ける方に交付する源泉徴収票や支払通知書等への個人番号の記載は行わないこととされました。詳しくはこちらをご覧ください。http://t.co/Hf7fdikhMG — 国税庁 (@NTA_Japan
#25歳までに経験しておきたいUNIX管理作業での失敗
案外成功方法より失敗集のほうがタメになりそう． ところでhost名がtaihaなのは安定性に関係ないです!!
小さなサーバーで大きなサービスをつくる | カメリオ開発者ブログ
アーキテクトのItoです。動画を撮るのが趣味ですが、最近はこの本を買って、カラーグレーディングの勉強をしています。とても良い本です。 さて、今回お話するのはバックエンドにあるフロントエンドについて。 以下はほぼ実際にカメリオで運用しているバックエンド構成です。 図中のサーバーというものはいわゆるHTTPベースのサーバーアプリで、ここでは緑をNode.js, グレーをPython, C++で実装しています。小さいサーバーがたくさんあります。主にクライアント〜フロントエンドAPIだけの構成図で、記事クローラーや各種管理画面などは図にはありませんが存在します。 まずフロントエンドにELB(AWSを使用)とNginxを置き、後ろに NodeベースのフロントエンドAPIサーバーを置きます。 ここはNode.jsで作られたアプリをサービスするごく一般的な方法です。 エンドポイント(api.kamel.
Facebookの数千台規模のmemcached運用について - ゆううきブログ
Linuxのブロックデバイスレベルで実現するrsyncより高速な差分バックアップについて - ゆううきブログの続きとして、Facebook の memcached 運用に関する論文を読んだ。 タイトルなどは以下の通り。 NSDI はネットワークシステムに関するトップレベルのカンファレンス。 Scaling Memcache at Facebook Rajesh Nishtala, Hans Fugal, Steven Grimm, Marc Kwiatkowski, Herman Lee, Harry C. Li, Ryan McElroy, Mike Paleczny, Daniel Peek, Paul Saab, David Stafford, Tony Tung, Venkateshwaran Venkataramani NSDI'13 In Proceedings of the
よろしい、ならば自動化だっ！ ～自動家の自動化哲学～ #AsianAA
Asian Automation Alliance ～自動化を語り合おう！(2014/06/28) にて発表した資料です。(約50分) 申し込みサイト : http://kokucheese.com/event/index/160374/Read less
急増するLINEインフラの課題と対応 « LINE Engineers' Blog
こんにちは。今回はITサービスセンターより、インフラ運営の観点から急増するLINEインフラの課題と対応について記させていただきます。 はじめに 先日開催したLINE Developer Conference（インフラ編）には大勢の方にいらしていただきました。カンファレンスでは、LINEサービスが始まってから約2年の間に我々はどういった方法でインフラ運営を行い、またどんなことに悩んできたのかを、システム、データベース、ネットワークの観点からそれぞれ発表させていただきました。 カンファレンスはLINE株式会社が様々な技術をどのように使い、どのように運用を行っているのか。現在どのような技術的なことに取り組んでいるのか日本のエンジニアの皆さんに知っていただくために開催されました。結果としてインフラ編では150名の定員に対して430名のご応募をいただいたとのことでLINEサービスに対する関心の高さを
第2回 世界的な分散・多重化で支えるルートサーバー
DNSルートサーバーのサービス停止はインターネットにとって致命的──。このリスクが改めて認識され、ルートサーバーの安定稼働に向けた強化が本格化したのは、2002年10月に起こった大規模なDDoS攻撃がきっかけだ。 この攻撃によって、当時の過半数のルートサーバーでDNS応答の遅延や、正常な応答が得られないといった障害が発生した。インターネット全体に致命的な障害が広がらずに済んだのは、攻撃の影響を受けなかったルートサーバーとDNSのキャッシュの仕組みによる。キャッシュDNSサーバーは問い合わせ済みの情報を、一定期間キャッシュとして保持する。そのため仮に全部のルートサーバーが停止しても、既にキャッシュ済みの情報を使ってしばらくの間は名前解決ができたわけだ。 とはいえ、このDDoS事件は関係者に改めてルートサーバー停止のリスクの大きさを意識させ、管理組織がルートサーバーの安定稼働のさらなる強化に乗
大規模障害から1年余り、あの企業が「その後」を語った
「この度は取材をお受けしましたが、どう対応したらよいか。今でも迷いがあります」。担当者は取材の冒頭で、心境をこう吐露した。 記者は取材のためレンタルサーバー事業を手掛けるファーストサーバ（本社：大阪市）を訪れた。1年半ほど前に、顧客企業が利用していたサーバー約5700台のデータをほぼ消失させる大規模障害を起こした事業者だ。 今回の取材は、過去に失敗を経験した複数の企業や公的団体に申し込んだ。目的は、「IT運用の失敗から技術者がどう学び、再発防止に取り組むべきか」をまとめる企画記事を執筆するためだ。 中でもファーストサーバは、運用のプロであるべきITベンダーが、一部とはいえ現場担当者のずさんな運用作業を見逃していた実態が明るみになり、個人としても大きな衝撃を受けた。失敗を経てどう体制を立て直したのか、大いに興味があった。 「非技術者」にも分かる再発防止策を：ファーストサーバ 簡単に、ファース
Linux用sar(sysstat)系コマンド実行管理＆グラフ化ツール - yushinの共有メモリ
sarとかvmstatとかiostatとかmpstatとか、 リソースステータスを見るコマンドを一定時間だけ実行し、 その結果を一気にグラフ化＆閲覧用HTMLを作成するツールをgithubに公開しました。 https://github.com/yushinhirano/resstat リアルタイムに見るのではなくて、ある期間だけグラフ画像で残す目的で使います。 たいていのLinux系のディストリビューションで動作します。 （テストしたのはRHEL系） こんな感じの出力になります。 インストール＆起動は本当に一瞬で終わります。 興味ある人は使ってみてください。（そしてフィードバックよろしくお願いします） 本当に簡単な使い方 sudo yum -y install zsh sysstat gnuplot expect git clone https://github.com/yushinhir
LTSVフォーマットなログを fluentd + GrowthForecast で料理 - naoyaのはてなダイアリー
ここ数年のデータ解析の重要性の高まりから、ログに関するソリューションが方々で活発に探求されている昨今でございます。ウェブサーバーの単純なアクセスログをそのまま保存するではなく追加情報を添加してみたり、あるいはアプリケーションから直接ログを吐いてそれらをデータウェアに投げ込んで･･･というのも当然のように行うようになりましたね。 しかしあまり自由度のない access_log の combined フォーマット。さてどうしたもんか･･･ ここで id:stanaka の登場です。 Labeled Tab Separated Valueというのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからflue
定期実行スクリプトの綺麗なロギング3選 - カイワレの大冒険 Third
オリンピックの流れに乗れてない@masudaKです。 職業柄かちょくちょくスクリプトを書くことはあるのですが、やはり色々自分で書いたり人のを見たりしてるうちに、この実行履歴綺麗だなーと思うことが多々あります。 今回は、そう思える対象のなかでも、「定期実行スクリプト」の「出力」を扱ってみたいと思います。 「定期実行スクリプト」というのは、バッチ処理だったり、何か必要に応じて叩かれるスクリプトで、具体的にはバックアップとか集計とか、一日に最低一回は叩かれるようなスクリプトです。cronやJenkinsで叩かれるような類ですかね。そのようなスクリプトの「出力」について書いてみたいと思います。 出力は標準出力であれば、tailfコマンドだったり、Jenkinsのビルドのコンソール出力で見られるようなもの。ロギングされてるのであれば、それと同様に追えるようなものとします。 以下に書くのはあくまで今の
東証、システム障害の原因は「人為ミス」、診断レポートを“解読”できず
東京証券取引所は2月16日、2月2日に発生した大規模システム障害について、「（東証の）職員が主体的にシステムの状態を確認せず、問題なしと判断した」ことが原因だったと発表した。東証のシステム子会社である東証システムサービス（TSS）の担当者と、保守ベンダーである富士通のSEが診断レポートを誤認し、東証の職員が経営陣に適切な報告を怠っていたことが、対応の遅れにつながったことも明らかにした（関連記事）。 障害を起こしたのは取引関係者に相場情報を配信する「情報配信システム」。サーバー3台を1セットとし、8セットで構成する。東証はサーバーを三重化しており、1台のサーバーに障害が発生した場合、残り2台に自動的に切り替えて処理を継続する。東証は切り替えに成功したと考えていたが、実際には失敗しており、同日午前中の一部銘柄の取引停止につながった。 経緯はこうだ。 午前1時27分、1台のサーバー（ノードA）で
災害にあったITシステムを操作しなければならない人が知るべきこと
東北地方太平洋沖地震が金曜日に発生し、被災された皆様には心よりお見舞い申し上げます。 そんな中でも、この月曜日から多くのIT関係者が被災したかもしれないITシステムの復旧に取りかかるのではないかと思います。そうした方々に役に立つ記事を届けられないだろうかと、ユニアデックスの高橋優亮氏に相談したところ、大いなるご賛同をいただき有志の方々とノウハウをまとめたこの文書「災害にあったITシステムを操作しなければならない人が知るべきこと v0.2」を作り上げていただきました。 本文書の主眼は被災したITシステムを復旧させようとする方々に向けた情報提供ですが、システムに電源を入れる前の注意事項、電源投入順序の考え方などの説明は、これから関東地方で計画されている停電が起きたあとのシステム再起動の際などにも参考になると思います。 本文書はどなたにでも活用していただけるようにGNU Free Documen
これがWikipediaの裏側、知られざる大規模システムの実態「Wikipedia / MediaWiki におけるシステム運用」
Wikipediaといえば世界で第5位の訪問者数を誇る巨大サイトですが、システム運営に携わる人間は世界でわずか6人、しかもこれはボランティア込みという恐るべき少人数で、第4位のFacebookのサーバ数が3万台を超えているのに対して、Wikipediaはわずか350台で運用している……などというような感じで、知られざる今のWikipediaの実態が「KOF2010」にて本日行われた講演「Wikipedia / MediaWiki におけるシステム運用」で明かされました。 登壇したのはWikipediaを運営するWikimedia財団のエンジニアであるRyan Lane氏で、100席ある座席は満席になり、隣の中継の部屋まで人があふれているほどの盛況っぷりで、語られる内容もなかなか参考になることが多く、今後のGIGAZINEサーバにも活かせそうな内容でした。 というわけで、「Wikipedia
FFTT : Capistrano
※ この資料について 2006年4月の勉強会資料をCapistranoのバージョンアップ（現時点では1.3.1になってました）による仕様変更などに合わせてちょっと修正したものです。 質疑応答の部分は当時のままなので最初の質問が初々しいです。 Capistranoって何なのさ デプロイツール デプロイ=配備 参考 : Capistrano: Automating Application Deployment 一言で言うと複数のサーバ上で同時に並行してコマンドを実行できるツール。 複数のサーバで動いているサービスのデプロイを楽に行うことができる。 Rails起源なのでRailsに特化した部分もあるが、ほかのアプリケーションでも使える。 昔はSwitchTowerと呼ばれていた。はてなでも使われてる。 何がいいのか 複数サーバへの作業が効率化、自動化できる 定義済みの標準タスクに沿った運用をする
保守を打ち切るというコスト削減策 | スラド
ITProにて、「保守を打ち切る」という中々男らしい？記事が掲載されている。 記事ではタイトルの通り、保守契約を打ち切ることで運用コストを減らすという事例を紹介している。たとえば、東京海上日動火災保険では求められる可用性が99.8％以下のシステムについてハードウエア保守を打ち切り、99.9％以上のシステムについても冗長構成を取っている場合は年間保守契約を外すということで、年間で3億円のコスト削減を実現した。パソナでは、保守サポート期間が切れたオラクル製データベースを使い続けることで年間で数千万円のコストを削減したということらしい。 ハードであればスポットで十分ということもあるし、ソフトでも問題に対応できる能力があれば古いソフトでも構わないというのは理解できる。ただ、どこでもお薦めできる削減策ではなさそうだ。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Icinga » Monitor your entire Infrastructure with Icinga
オシャレエロサイトをリリースして、10万PV/日を捌くためにやったこと - 彼女からは、おいちゃんと呼ばれています
Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution
