VPN・証明書はもう不要? Azure ADによるデバイス認証 at Tech Summit 2018
![CMDBuildを中心とした運用管理自動化基盤OpenPIEの事例紹介](https://cdn-ak-scissors.b.st-hatena.com/image/square/29678d76dec86eff5d6fbad4a93e89706bc01205/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F151201openpie-151201071135-lva1-app6892-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
マイナンバー制度の関連システムを運用する地方公共団体情報システム機構(J-LIS)は2016年1月25日、同日まで断続的に「カード管理システム」で障害が発生し、一部の自治体(市区町村)で個人番号カード交付などの業務が滞ったと発表した。 J-LISは既に1月13日、18日、19日にもシステム障害が発生したことを明らかにしている。その後、21日、22日、25日にもそれぞれ10~40分程度障害が発生し、自治体からの処理要求の一部をこなせなくなった。 J-LISの説明によれば、21日以降の障害はいずれも「住基ネット中継サーバー2号機」の動作が不安定になったことが原因である(図)。2号機では18日と19日にも障害が発生したが、部品交換によっていったん収束した(関連記事:部品交換でマイナンバー「中継サーバー」障害解消、根本原因はなお不明)。だがその後も再発を繰り返している。 根本的な原因は今も分かって
こんにちは、井上です。 最近好きな番組は「しくじり先生」です。 毎回、何かしらでしくじった諸先輩方が出演し、しくじった体験談と、それを元にした教訓をおしえてしてくれる番組なのですが、実体験に基づくだけあって教訓も説得力があり、非常にためになります。 辺見マリが洗脳されて5億円とられた話とか、生々しすぎて恐怖でした。 それにちなんで、今回はAWSの利用でしくじった話をしようと思います。 今回私がしくじったサービスは、ElasticBeanstalkです。 ElasticBeanstalkは簡単に説明すると、WEBアプリケーションのデプロイ、構成管理、オートスケールなどをまるっと面倒を見てくれる便利なサービスです。 2014年の4月くらいから利用検討を開始し、最初の頃は情報も少なく手探りの状態からスタートしました。 特に ebextensions で設定する構成管理の部分にクセがあり、どのよう
IT界隈でエンジニアしていると、よく出くわすのが障害対応です。できれば会いたくないという人が多いと思うんですが、僕はけっこう好きです。障害対応。どこに原因があるのか調査をして、バランス良くベターな対応をしたときの楽しさは、プログラミングとはまた違ったものがあります。探偵っぽい感じが面白いですよね。もちろん、障害が発生しない状況を作るのが一番です 弊社では数多くのWebサービス/アプリを運営しているので、過去様々な障害対応をしてきました。その際に、解決までどんな道筋を僕がたどるのかを振り返ってまとめてみました。これが大正解なんてことはなく、人や事象によって違うとは思いますが。 なお、障害検知手法とか、サーバのコマンドとか、コードのデバッグ手法とか、具体的なことは一切出てきません。手続きと思考プロセス的な話です。 障害対応フローチャート 一般的な感じだと思いますが、障害報告から対応完了までのフ
「ネットワーク運用の自動化」として、BGP経路監視を考察してみたいと思います。 NetOpsCoding Advent Calendar 2015 12/12分のエントリーです qiita.com ◾️ ”BGP運用”という言葉から想定されるイメージ BGP運用というと、なんとなく「BGP職人さん」という言葉を連想してしまうのは、私だけでしょうか? BGP職人さんは、事前に策定されたBGP運用ポリシーに従って、ポリシー・ルーティングに関わるルートマップ等コンフィグを投入することができる存在であり、想定どおり、ポリシー・ルーティングが動作されているかを確認するため、ベンダ固有のCLIコマンドを駆使して細かなBGP制御を確認することを日々の業務として実施する。 そんなイメージを、「BGP運用」からは、連想してしまいます。 さらに、不測な事態としてNWトポロジが安定動作していないことが判明した際
こんにちは、North America事業本部のLiang Fanです。このエントリーは GREE Advent Calendar 2015 10日目の記事です。 本日は、以前所属していたインフラストラクチャ部のサーバ運用と自動化の話を少しご紹介したいと思います。 よろしくお願い致します。 はじめに 運用自動化と聞いて、みなさんは頭の中に何を浮かべますか?仮想化技術(docker、VM)、構成管理ツール(chef、puppet)やクラウドサービス(AWS、Google Cloud Platform)などの答えがたくさん出てくるかもしれません。本日はそれらの技術を使って、かっこいい運用自動化ができたという話ではなく、レガシー環境のサーバ運用を少しでも楽にするための泥臭い自動化の話を紹介したいと思います。 グリーのレガシー環境 レガシー環境と言っても、もう歩けない80歳のおじいさんではなく、
諸君、私は運用が大好きだ! 監視が好きだ 監視設計が好きだ アラートが好きだ パトランプが好きだ データセンタの入館申請が好きだ Muninも好きだ Zabbixも大好きだ トラブルシュートが好きだ 報告書作成が好きだ データセンタで オフィスで 公園で 映画館のロビーで この地上で行われる ありとあらゆる運用が大好きだ ――とある運用担当者の手記より。作者は不明である。 本稿は、Zabbix アドベントカレンダー 2015 の、12月9日分の投稿です。想定している読者は、Zabbix や運用・監視といったキーワードに興味をお持ちの方です。 ■ 概要(はじめに、運用があった) 先日、Zabbix Conference Japan 2015 で登壇の機会をいただきました。その発表内容の前半、「そもそも、わたしは何故 Zabbix を導入したのか」を、改めて文章として紹介したいと思っています。
こんにちは。村主です。 前回(↓)の記事の反響が多かったので、少し掘りげて技術的なところを書きます。 muranonushi.hatenablog.jp 今回の趣旨 前回の「内部の見える化のための、リソース系の情報取得」を実装する。 リソース系の情報をCloudWatchにPutしてみよう 1. EC2作成 EC2作成手順はあちこちにあるのでGoogle先生に聞いてください。 注意点は、EC2作成時にIAMロールを付与してください。 2. IAMロール割り当て EC2作成時に割り当てるIAMロールのポリシーは以下でOKです。 IAMロールを割り当ててないEC2で行う場合は、IAMを発行の上で アクセスキー・シークレットキーを発行し、ポリシー付与などの対応ください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "Stmt1449132
ある日、 PR の内容を見ずにマージすることを岡島(ピッチャーの)というらしい 笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね!— そーだい@初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。 #ブログ待ってます— そーだい@初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、本当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基本
サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 米国でビデオオンデマンドサービスを提供しているNetflixは、Amazonクラウド上でわざとシステム障害を起こすためのツール、Chaos Monkeyをオープンソースで公開しました。 Chaos MonkeyはAmazonクラウド上で使うツール。Amazonクラウド上のインスタンスをランダムに落としまくることで、サービスに対して仮想的な障害を引き起こしてくれます。 NetflixはこのChaos Monkeyを実環境で使うことで、本物の障害が起きたとしてもサービスが継続できることをテストし続けてきました。Netflixのブログ「Chaos Monkey released into the wild」から引用します。 There are many fail
たまに検討するけど、よく忘れるのでまとめておく。ごく個人的な感想としては、Rundeck, Azkabanあたりで始めてみるのがいいかもと思う。 要件 重複実行の防止 ジョブの実行結果、かかった時間、ログ出力などが見れる 失敗時の通知 候補 OSS系 Rundeck http://rundeck.org/ Java Runtimeで動く RUNDECK PROという有料サービスもある http://simplifyops.com/ 参考: http://heartbeats.jp/hbblog/2015/01/rundeck.html Oozie http://oozie.apache.org/ Workflow Scheduler for Hadoop Java http://oozie.apache.org/docs/4.1.0/DG_Overview.html Webコンソールもある
はじめに こんにちは植木和樹@上越妙高オフィスです。AWS上でのインフラ構築が終わり、アプリケーションがデプロイされるといよいよサービスローンチ。数日〜数週間様子をみて問題がなければ運用チームに業務を引き継ぐことが多いかと思います。 運用チームへの引き継ぎ資料を作って「あとはよろしくね」となるわけですが、その段階で「待て」がかかってしまうことがあります。(だいたい待てを言うのは私なんですが) 今回はスムーズに運用チームに業務引き継ぎができるように、私が注意しているポイントをまとめておきたいと思います。 3つのポイント 注意するポイントは3つです。 1. Input なにをトリガーに作業が始まるのか。どんな通知がくるのか。 2. Action 何をするのか。 3. Output 作業が終わったら誰に報告するのか。 1つずつ説明していきます。 1. Input 運用チームは基本的に「イベント・
Ansible と Mackerel API を組み合わせて、1000台規模のサーバ群に対して同時にパッケージの更新やその他のサーバオペレーションのための方法を紹介します。 タイトルに Mackerel とありますが、それほど Mackerel に依存しない話です。 (AnsibleとDockerによる1000台同時SSHオペレーション環境 - ゆううきブログに続編を書いています。) 背景 社内では、サーバ構成管理ツールとして Chef を使用しています。 Chef Server は運用が大変なので使用しておらず、knife-solo と Mackerel APIを組み合わせてホストと Chef role とのマッピングに Mackerel のロール情報を用いています。 また、Mackerel の Ruby クライアントを利用して recipe 内で API を叩いて、Mackerel か
『ユーザーストーリーマッピング』 出会いと適用 / User Story Mapping encounter and application
最近の開発で仕様書等のドキュメント類を書くことが少なくなりました。 私は主に業務系のWebサービスを作成してましたが、最近はオープン系のサービスも受け持つことも多いのですが、仕様書やテストのエビデンスがオープン系のお客様の場合は求められることが少ない・・・ というかほぼない。 何故、お客様は仕様書を求めないのか? 予算を削りたい お客様にとって仕様書なんて見てもわからないもの貰ってもしょうがない。 貰ってもしょうがないものなら作ってもらわないで、削ってしまおうって考えがあります。 テストのエビデンスも同様です。 これは仕様書の作成やエビデンスの作成に工数が掛かるため、工数の削減を計って予算を削りたいという考えがあります。 例えば、おおまかに計算しますが以下のようなシステムがあります。 開発工数:1人月 検証工数:0.5人月 設計工数:0.5人月 ドキュメント作成工数:0.5人月 管理工数:
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く