TOP /  運用管理/運用自動化 /  「正常ログ」からシステム障害を予測する

「正常ログ」からシステム障害を予測する | 運用管理/運用自動化

講演資料を見るには、 プライバシーポリシーに同意して、送付先メールアドレスをご入力しご請求ください。

またご入力いただきました情報は、当該イベントの主催・共催・協賛・講演企業とも共有させていただき、 当社及び各社のサービス、製品、セミナー、イベントなどのご案内に使用させていただきます。

メールアドレス


法人様向けの資料のため、フリーアドレスをご利用の場合は、会社名、お名前を入力してください。
会社名
お名前

ラックが考える、システム運用の課題と、「正常ログ」からの障害予測  (株式会社ラック 津村)

講演資料を見るには、 プライバシーポリシーに同意して、送付先メールアドレスをご入力しご請求ください。

またご入力いただきました情報は、当該イベントの主催・共催・協賛・講演企業とも共有させていただき、 当社及び各社のサービス、製品、セミナー、イベントなどのご案内に使用させていただきます。

メールアドレス


法人様向けの資料のため、フリーアドレスをご利用の場合は、会社名、お名前を入力してください。
会社名
お名前

セミナー全体の評価と、参加者からのコメント

参加者によるこのセミナーの評価は、
3.2 でした!(5点満点中)
セミナー名 「正常ログ」からシステム障害を予測する
講演企業 株式会社ラック
開催日 2016年07月26日
企業に対してITを提供する企業(ベンダー、SIerなど) 30代 男性 の参加者
運用保守サービスベンダーの試みが知れて良かったです。
企業に対してITを提供する企業(ベンダー、SIerなど) 40代 男性 の参加者
2製品だよりなのが。。。
消費者に対してITを提供する企業(Webサービス、ゲームなど) 30代 男性 の参加者
運用視点で全体の課題が順調に洗い出され、ログ管理を超えて未然に異常点を見つけ出す方法論が勉強になりました。
企業に対してITを提供する企業(ベンダー、SIerなど) 30代 男性 の参加者
内容的に実績に基づいたものが聞けると思っていました。その点は残念ですが内容的には非常に興味がありますので、次回も開催を期待したいです。
その他 40代 男性 の参加者
少し見づらかったです。
匿名の参加者
コメントなし
企業に対してITを提供する企業(ベンダー、SIerなど) 20代 男性 の参加者
導入事例があれば理解しやすく、導入してみたくなる企業もあったかと思います。
インフォコム株式会社 江頭 健一郎さん
デモを丁寧にみせて頂けて、使用イメージがつかみ易かった。
企業に対してITを提供する企業(ベンダー、SIerなど) 50代 男性 の参加者
スクリーンが隠れるので、レーザーポインターを使った方が良い
企業に対してITを提供する企業(ベンダー、SIerなど) 20代 男性 の参加者
実際のデータを使用した具体例があれば良かった
企業に対してITを提供する企業(ベンダー、SIerなど) 60代以上 男性 の参加者
プレゼンに工夫が必要と感じました。結局何がでいるのかプレゼンだけではわからなかった。
匿名の参加者
技術的な話題の深堀をして欲しかったです。
企業に対してITを提供する企業(ベンダー、SIerなど) 30代 男性 の参加者
一例としてのSplunkを使って運用についてお聞きでき興味深かったです。また、今試行錯誤しものを作られていることが面白かったです。
消費者に対してITを提供する企業(Webサービス、ゲームなど) 30代 男性 の参加者
コメントなし
企業に対してITを提供する企業(ベンダー、SIerなど) 30代 男性 の参加者
コメントなし
企業に対してITを提供する企業(ベンダー、SIerなど) 30代 女性 の参加者
コメントなし
企業に対してITを提供する企業(ベンダー、SIerなど) 50代 男性 の参加者
コメントなし
企業に対してITを提供する企業(ベンダー、SIerなど) 40代 男性 の参加者
予測の話がほとんどなかったのが残念
匿名の参加者
コメントなし
消費者に対してITを提供する企業(Webサービス、ゲームなど) 40代 男性 の参加者
もう少しAppsを1つ具体的に拾って説明して欲しかった。
企業に対してITを提供する企業(ベンダー、SIerなど) 30代 男性 の参加者
今後のログ監視のあり方の概念を知る点と、具体的なSplunkというツールを知ることができた点は、良かった。
匿名の参加者
具体的なイメージが付きにくかった
企業に対してITを提供する企業(ベンダー、SIerなど) 50代 男性 の参加者
予想以上に面白かったです。実際B2Bでは運用のほうが開発・構築より課題が多いと思いますので、この分野でのお話を今後も期待します。
官公庁・自治体 50代 男性 の参加者
ログから障害をみつけるノウハウ的なものを期待していたので。。。。 (ADログに場合はここを見る、ファイルサーバーの場合はここを見るなど)
匿名の参加者
コメントなし
匿名の参加者
運用設計のアプローチ方法が分かった。
株式会社ショーケース・ティービー 弓削田公司さん
少し分かりずらかった。参加している人のスタンス、事前知識など欲しかった。

「正常ログ」から障害の予兆を検知する
~Governance・Risk・Compliance~
2016年07月
株式会社ラック
津村賢哉
ビジネス変更に
伴う機能追加
Cloud
Web
Servers
3rd Party/
Cloud Services
Local
ISP
障害時
運用
運用リーダーB
Storage
ベンダーI
保守
Data Center
通常
運用
Virtual/Physical Environment
Major
ISP
Load
Balancers
Web
Servers
App
DB
Servers Servers
Mainframe
Storage
DB
App
Servers Servers
Mobile
Carrier
ベンダーA
障害時
運用
運用責リーダーC
保守
Network
WAN
Optimization
Mobile
Components
Devices
Storage
Akamai
(CDN)
Employees
App
Servers
Customers
Browsers
Networkデバイ
スのEOSで更改
通常
運用
Web
Services
通常
運用
障害時
運用
保守
仮想化
運用責任者D
DR Center
ITには数々の専門知識が必要であり、必然的にサイロが形成
Load
Web
App
DB
Virtual/Physical Environment
通常
運用
障害時
運用
全体を見渡しずらい
新しいセキュリ
ティ脅威への対システム


• チーム
• プロセス
Network
Storage
社内システム
通常
ビジネス企画、要件定義、デジタルマーケティング(流入対策、リードジェネレーションなど)、ミドルティ
Balancers Servers Servers Servers Mainframe
運用
アへの対策、セキュリティ、Web・AP・DB/ミドルウェア/ネットワークの設計・構築・管理・・・ 障害時
運用
保守
:現状がわからない、予兆がわからない、将来もわからない
WAN
Mobile
Web
ビジネス拡大
Optimization
Components
Services
:サイロ型の思考から責任の擦り付け合い、特定の有識者への依存
に対応した資
:各責任部門が集まって、全体の把握と分析、対策を検討。
源増強
ネットワーク運用リーダーA
保守
Copyright ©LAC Co., Ltd. All Rights Reserved.
運用設計
目的
サービスの安定化
運用業務(コスト)の
可視化
運用設計項目例
1.基本方針
2.業務内容
・システムが実現する業務の概要
・システム利用者
3.システムの管理項目
・システム運用の中で管理する項目
4.システム運用体制
・運用者及び管理者
5.運用スケジュール
・日次・月次等の作業スケジュール
・定期作業項目/不定期作業項目
6.監視設計
・監視方式/監視項目
・ログ設計/取得するログ一覧
7.バックアップ設計
・方式/対象データ/容量見積/世代管理
・バックアップスケジュール
8.障害対応
9.災害対応
10.JOB管理設計
・JOB一覧
・異常時の対応
変化と複雑化排除
・対象の固定
・タイミングの固定
・項目の固定
有事偏向
・トラブルの発見
・対応の手順化
オペレータさんに
渡すからね
Copyright ©LAC Co., Ltd. All Rights Reserved.
運用設計
ログは点在している
ログの追跡が困難
ログの保存期間が統一できない
ログの形式がバラバラ
6.監視設計
・監視方式/監視項目
・ログ設計/取得するログ一覧
種類
論理ホスト設定プログラムログ 最大ディスク ファイルの切
SNMPトラップ変換機能ログ(定義情報) 占有量
り替え時期
Base_Path¥log¥JBS_SPMD{1|2|3}.log
0.375 128KB
Base_Path¥log¥JBS_SPMD_COMMAND{1|2|3}.log
0.375 128KB
Base_Path¥log¥JBS_SERVICE{1|2|3}.log
0.375 128KB
共有フォルダ¥jp1base¥log¥JBS_SPMD{1|2|3}.log
0.375 128KB
共有フォルダ¥jp1base¥log¥JBS_SPMD_COMMAND{1|2|3}.log
0.375 128KB
共有フォルダ¥jp1base¥log¥JBS_SERVICE{1|2|3}.log
0.375 128KB
※12
Base_Path¥log¥jbssessionapi.log{1|2|3|4|5|6|7|8}.log
2 256KB
%ALLUSERSPROFILE%¥Hitachi¥JP1¥jp1_default¥JP1Base¥log¥jbssessiona
2 256KB
※13※14
pi.log{1|2|3|4|5|6|7|8}.log
Base_Path¥log¥jbssessionCmd.log{1|2|3|4|5|6|7|8}.log
2 256KB
Base_Path¥log¥jbssessionmgr{1|2|3|4|5|6|7|8}.log
2 256KB
Base_Path¥log¥jbssessionmgr_trace{1|2|3|4|5|6|7|8}.log
2 256KB
※12
共有フォルダ¥jp1base¥log¥ jbssessionapi.log{1|2|3|4|5|6|7|8}.log
2 256KB
%ALLUSERSPROFILE%¥Hitachi¥JP1¥論理ホスト名
2 256KB
※13※14
¥JP1Base¥log¥jbssessionapi.log{1|2|3|4|5|6|7|8}.log
共有フォルダ¥jp1base¥log¥ jbssessionCMD.log{1|2|3|4|5|6|7|8}.log
2 256KB
共有フォルダ¥jp1base¥log¥ jbssessionmgr{1|2|3|4|5|6|7|8}.log
2 256KB
共有フォルダ¥jp1base¥log¥ jbssessionmgr_trace{1|2|3|4|5|6|7|8}.log
2 256KB
Base_Path¥log¥JBSSESS{1|2|3|4|5|6|7|8}.log
2 256KB
共有フォルダ¥jp1base¥log¥JBSSESS{1|2|3|4|5|6|7|8}.log
2 256KB
Base_Path¥log¥jp1bssetup{1|2}.log
0.125 64KB
共有フォルダ¥jp1base¥log¥jp1bssetup{1|2}.log
0.125 64KB
Base_Path¥log¥jp1hasetup.{log|log.old}
2 1,000KB
Base_Path¥log¥imevtgw.conf{1|2|3}.log
3 1MB
SNMPトラップ変換機能ログ(監視情報) Base_Path¥log¥imevtgw.log{1|2|3}.log
プロセス管理ログ
認証サーバログ
認証サーバ設定コマンドログ
環境設定プログラムログ
イベント設定一元管理取得コマンド用トレースログファイル
デフォルトのファイル名・フォルダ名
15 5MB
この中からシナリオに合わせて
Base_Path¥sys¥tmp¥event¥servers¥default¥jevdef_get.{000|001|002}
0.0625 コマンド実行
エラー、ワーニングを拾い

共有フォルダ¥jp1base¥event¥jevdef_get.{000|001|002}
0.0625 コマンド実行
手順化する。


4
※4
イベント設定一元管理配布コマンド用トレースログファイル
Base_Path¥sys¥tmp¥event¥servers¥default¥jevdef_distrib.{000|001|00
※4
2}
※4
共有フォルダ¥jp1base¥event¥jevdef_distrib.{000|001|002}



0.0625 コマンド実行

0.0625 コマンド実行

Copyright ©LAC Co., Ltd. All Rights Reserved.
運用設計
ログ発生時
(リアルタイム)
定期的
(短いいサイクル)
運用シナリオ想像して
異常なLOG以外を捨てて
絞り込むアプローチ
定期的
(長いサイクル)
発生時
トラブルを知る
エラー結果/正常結果
選んだLOG
エラー結果と過程サマリ
正常結果と過程サマリ
エラー結果と過程そのもの
正常結果と過程そのもの
すべてのLOG
Copyright ©LAC Co., Ltd. All Rights Reserved.
時間がかかる
サービスイン後にDB
サーバのCPU使用率が
予想より高くなってて
気になる
けどランキュー長は
ほぼ一定
トランザクションは
徐々に下がる
ユーザーレスポンスは
ほぼ一定
CCにクレームも増え
てない
IT運用部門
DB担当者
どんどん
時間が
過ぎる
担当者と打合せ調整
打合せで調査依頼
IT運用部門
調査結果を共有
分析
Web担当者
担当者と打合せ調整
打合せで調査依頼
調査結果を共有
LOB
分析
ECサイト担当者
重要度(Severity)決定
対策検討
複数の切り口のデータを
時間軸をそろえて
相関分析
Copyright ©LAC Co., Ltd. All Rights Reserved.
「正常ログ」から障害の予兆を検知する
(LOBからなんか言われる前に対処済~)
Detection(検出)
通常時との違い発見する
Diagnostic(診断)
調査、選別、相関関係、検証
予兆の発見
ログの突合
Remediation(修復)
必要な対策を実行する
Escalation(エスカレーション)
共有、必要な対策へのジャッジを求める
対処する
対策実績と突合
予測
Learning(学習)
既知の予兆として対策を共有、未知の予兆へ備え蓄積
する
フィードバック
既知化する
Copyright ©LAC Co., Ltd. All Rights Reserved.
「正常ログ」から障害の予兆を検知する
予兆の発見に必要なデータ
フェーズ データ
(前処理)
備考
データの収集と意味を把握した格納
タイムスタンプ付加
インデックス付加
通常時との違い発見する
現在の正常時データ
過去の正常時データ
正常値範囲(閾値)
調査、選別、相関関係、検

予測で微調整
過去のパターン
相関分析対象の判別データ
収集元
予兆分類(既知か未知分類)情報
予兆判定基準情報
閾値判定基準情報
予兆のプライオリティ情報
Copyright ©LAC Co., Ltd. All Rights Reserved.
「正常ログ」から障害の予兆を検知する
セキュリティ対策の場合はぜんぜん捨てられない
全部とります。統計学的な異常値も大切だし。
×保存期間
×サービスが関係する全デバイス
取得タイミング
ログ発生時
(リアルタイム)
予兆を発見する
定期的
(短いいサイクル)
定期的
(長いサイクル)
発生時
トラブルを知る
エラー結果/正常結果
選んだLOG
正常LOGを
全部とっとく
KPIを設定する
アプローチ
エラー結果と過程サマリ
正常結果と過程サマリ
エラー結果と過程そのもの
正常結果と過程そのもの
すべてのLOG
Copyright ©LAC Co., Ltd. All Rights Reserved.
「正常ログ」から障害の予兆を検知する
いつもと違う
(けどシステムは正常に見える)
Current
過去の推移からの
予測の世界
いつもの範囲
・いつもの世界を把握していないと違いを発見できない
・いつもの世界を把握していないと将来を予測できない
・サービスに関係する範囲は全部関係あるはず
Copyright ©LAC Co., Ltd. All Rights Reserved.
システム全体可視化
GRC(Governance・Risk・Compliance)プラットフォーム
ユーザー視点からの可視化(CEM)
全ユーザー・全トランザクションを一気通貫に可視化
ビジネス企画、
デジタルマーケティング
利用者
クラウド
パブリック プライベート
ブラウザ、
デバイス
キャリア
3rd パーティ
データセンター
他のシステム
セキュリティ
ISP
他のシステム
WEB
モバイル
DB
AP
CDN
他のシステム
仮想環境
ユーザー体験、
画面UI
ネットワーク
(ミドルマイル)
ネットワーク
インフラ視点・アプリ視点の管理
インフラ、アプリを個別に監視・管理
Copyright ©LAC Co., Ltd. All Rights Reserved.
システム全体可視化
GRC(Governance・Risk・Compliance)プラットフォーム
apps:データの収集とデータの意味を把握した格納
Copyright ©LAC Co., Ltd. All Rights Reserved.
Splunkによるアラート送信
アラート設定により極端に
パフォーマンスが悪化した
際に管理者に通知
Base Log Line Data
Name Value
type The 'type' of EdgeConnect API represented by this message. Currently the only available type is
"cloud_monitor"
format This is the format of the log line. The available options are : "default", "bmc_apm" . This may also be
referred to as the 'connector', but there may be multiple connectors that share a message format.
version The version of the connector being used. Examples : "1.0", "1.1", "2.0"
id A globally unique ID created to identify this specific message.
start This is the epoch time, to millisecond precision, of when the Akamai Edge Server initiated the connection
for the message exchange (Req/Resp cycle when the message is HTTP) being monitored.
cp The customer cpcode.
Optional
Message Exchange Data
Splunkの機能に依存するが、
これらのデータによりBad
IPからのアクセスの挙動が監
視可能と想定
Name Value
proto The protocol of the transaction being monitored. Currently HTTP | HTTPS
protoVer The version of the protocol : 1.0 | 1.1
cliIP The IP address of the client that connects to
reqPort The port number of the incoming client request.
reqHost The value of the 'Host' header of the incming client request
The 'method' of the incoming request - assuming an HTTP request. GET | POST | PUT
| HEAD etc.
The path used in the incoming URI from the client, not including query strings
The query strings passed in the incoming URI from the client
The value of the 'Content-Type' header in the client request
The value of the 'Content-Length' header in the client request
If the request was over SSL, this will be the version of SSL / TLS used.
The HTTP Response status sent to the client
The value of the 'Location' header sent to the client in the case of a 301|302 HTTP
response to the client
The value of the 'Content-Type' header in the client response
The value of the 'Content-Length' header in the client response
The content bytes served in the client response.
The value of the User-Agent header in the client request
The hostname of the forward origin server (where an Akamai Edge server sends a
request)
reqMethod
reqPath
reqQuery
reqCT
reqLen
sslVer
status
redirURL
respCT
respLen
bytes
UA
fwdHost
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Request Header Data
Name Value (Corresponding Request Header Name)
Optional
accEnc Accept-Encoding Optional
accLang Accept-Language Optional
auth Authorization Optional
cacheCtl Cache-Control Optional
conn Connection Optional
contMD5 Content-MD5 Optional
cookie Cookie Optional
DNT DNT Optional
expect Expect Optional
ifMatch If-Match Optional
ifMod If-Modified-Since Optional
ifNone If-None-Match Optional
ifRange If-Range Optional
ifUnmod If-Unmodified-Since Optional
range Range Optional
referer Referer Optional
te TE Optional
upgrade Upgrade Optional
via Via Optional
xFrwdFor X-Forwarded-For Optional
xReqWith X-Requested-With Optional
Response Header Data
Name Value (Corresponding Response Header Name) Optional
accRange Accept-Ranges Optional
allowOrigin Access-Control-Allow-Origin Optional
age Age Optional
allow Allow Optional
cacheCtl Cache-Control Optional
conn Connection Optional
contEnc Content-Encoding Optional
contLang Content-Language Optional
contMD5 Content-MD5 Optional
contDisp Content-Disposition Optional
contRange Content-Range Optional
date Date Optional
eTag ETag Optional
expires Expires Optional
lastMod Last-Modified Optional
link Link Optional
p3p P3P Optional
retry Retry-After Optional
server Server Optional
trailer Trailer Optional
transEnc Transfer-Encoding Optional
vary Vary Optional
via Via Optional
warning Warning Optional
wwwAuth WWW-Authenticate Optional
xPwrdBy X-Powered-By Optional
setCookie Set-Cookie Optional
Network Performance Metrics
Name
Splunkの機能に依存するが、これらの
データを使用しパフォーマンスが極端に悪
化した場合にアラート通知が可能と想定
Value
Optional
downloadTime The time, in milliseconds from when the Edge Server first accepts the request to
when it sends the last byte (not when the client acknowledges receiving the last
byte)
originName When using Edge Load Balancing w/Alta, this is the Friendly Name assigned to the
Optional
"Origin" container
originIP
This is the IP address of the data center that served the response. This is available
when using Alta's Edge Load Balancing. Other traffic products will require PS support
to enable it.
originInitIP
This will be a conditional element only present when a fail-over event happens. This
will be the IP of the data center for the first attempt.
originRetry This will be a conditional element only present when a fail-over event happens. This
will be the # of times the forward request was retried during fail-over.
lastMileRTT Time, in milliseconds, that reprents the TCP round trip time observed between the
Akamai Edge Server and the client device connecting to it
midMileRTT
Time, in milliseconds. If this request goes through an Akamai parent server, this
should represent the cumulative TCP round trip times between the Akamai servers
on the path of the message exchange. This element needs further analysis to verify
its accuracy.
midMileLatenc Time, in milliseconds. If this request goes through an Akamai parent server, this
y
should represent the time in network for that segment for the message exchange.
This element needs further analysis to verify its accuracy.
netOriginLaten Time, in millilseconds, from when the last byte of the request left the Akamai Edge
cy
Server and when the first byte of the response was received from the Edge Server.
Includes origin 'think time' - the time it takes the origin to process the request before
delivering the response.
Network Performance Metrics (continued)
Name Value
lastMileBW Value : Bandwidth Range
cacheStatus 1
: 1 - 55 Kbps
56 : 56 - 255 Kbps
256 : 256 – 999 Kbps
1000 : 1000 - 1999 Kbps
2000 : 2000 - 4999 Kbps
5000 : 5000 Kbps and higher
0 : Non cacheable request per content rules
1 : Cache hit at the Edge
firstByte
lastByte
asnum
network
netType
edgeIP
2 : Cache hit on an Akamai cache-hierarch server. Subesequent request for object will
probably be served from cahe at the edge.
3 : Content is cacheable, but was not served by Akamai cache. This request was sent
forward to the origin.
The first byte of the object has been served to the client. '1' would indicate yes, and
'0' otherwise.
The last byte of the object was served by this response. '0' would indicate part of a
byte-range response
Autonomous Systems Number for the client request
Needs validated
Needs validated
The IP address of the Akamai Edge Server that served the response to the client. This
is useful when resolving issues with Akamai's Customer Care team
Optional
Web Application Firewall (v1)
Name Value
logVer The version of the log format
ipRules The ID of the IP blocking rule set that is active
appRules The ID of the application rule set that is active
lastByte The last byte of the object was served by this response. '0' would indicate part of a
byte-range response
WAF firewall rule(s) that triggered the warning
WAF firewall rule(s) that triggered the deny event
warn
deny
Optional
システム全体可視化
GRC(Governance・Risk・Compliance)プラットフォーム
Microsoft
Windows
CISCO
Unix
and Linux
IBM
WebSphere
Application Server
サービスに関係するのはどれですか?
Copyright ©LAC Co., Ltd. All Rights Reserved.
システム全体可視化
GRC(Governance・Risk・Compliance)プラットフォーム
Microsoft
Windows
アプリケーション、システム、セキュリティのイベントログ情報
CPU、メモリ、ディスク、ネットワークのパフォーマンス指標
Windows Updateの履歴
アプリケーション使用状況指標
Copyright ©LAC Co., Ltd. All Rights Reserved.
GRCプラットフォームの機能
(LOBからなんか言われる前に対処済~)
サーバー
・リアルタイムモニター
・トラブルシュートデータ
・使用率レポート
・予兆管理
DBサーバー
・リアルタイムモニター
・トラブルシュートデータ
・使用率レポート
・サービスKPI管理
・予兆管理
アプリケーション
・リアルタイムモニター
・トラブルシュートデータ
・使用率レポート
・サービスKPI管理
・ユーザー体感管理
・コンバージョンレイト管理
・ストラグル管理
ストレージ
・リアルタイムモニター
・リソース管理
・サービスKPI管理
・予兆管理
ネットワーク
・リアルタイムモニター
・トラブルシュートデータ
・トレンド分析
セキュリティ
etc..
Copyright ©LAC Co., Ltd. All Rights Reserved.
自動化を考える
Copyright ©LAC Co., Ltd. All Rights Reserved.
自動化を考える
弊社のDCの場合:手作業の割合が48%
2人でハンコの世界
Copyright ©LAC Co., Ltd. All Rights Reserved.
自動化を考える
既知のものは自動化できる
Detection(検出)
通常時との違い発見する
Diagnostic(診断)
調査、選別、相関関係、検証
予兆の発見
ログの突合
Remediation(修復)
必要な対策を実行する
Escalation(エスカレーション)
共有、必要な対策へのジャッジを求める
対処する
対策実績と突合
予測
Learning(学習)
既知の予兆として対策を共有、未知の予兆へ備え蓄積
する
フィードバック
既知化する
Copyright ©LAC Co., Ltd. All Rights Reserved.
自動化を考える
自動化、あるいは
急いで作業フロー実施
Diagnostic(診断)
調査、選別、相関関係、検証
Remediation(修復)
必要な対策を実行する
予兆の発見
Escalation(エスカレーション)
共有、必要な対策へのジャッジを求める
既知のものか?
未知のものか?
比率 ・対応
を増
スピード
やす
向上
・省力化
Learning(学習)
既知の予兆として対策を共有、未知の予兆へ備え蓄積する
人が実施する
Diagnostic(診断)
調査、選別、相関関係、検証
Remediation(修復)
必要な対策を実行する
Escalation(エスカレーション)
共有、必要な対策へのジャッジを求める
比率
を減
らす
Learning(学習)
既知の予兆として対策を共有、未知の予兆へ備え蓄積する
Copyright ©LAC Co., Ltd. All Rights Reserved.
自動化を考える
Copyright ©LAC Co., Ltd. All Rights Reserved.
自動化を考える
Copyright ©LAC Co., Ltd. All Rights Reserved.
自動化を考える
Copyright ©LAC Co., Ltd. All Rights Reserved.
ロードマップ
コグニティブ
コンピューティング
エンジニアの
仮想化
(予兆への素早く反応)
システム全体の
可視化
・全体を把握
・既知の予兆と
未知の予兆の仕分け
・既知の予兆の自動化
(人間の判断を減らす)
・人間は未知の予兆へ
集中
・予兆の機械学習
・未知の予兆へ必要な対応を
予測(確信度)
・確信度の高い予兆への
自動対応I
・人間は結果の振返りを行い
確信度と結果のパラメターを
調整
グーグルは、データセンターの冷却に使う
電力を、人工知能(AI)で4割節約するこ
とに成功した。活躍しているのは、人間の
プロ囲碁棋士を破ったことで話題になった
DeepMindだ。
囲碁で人間に勝利したグーグルの人工知能、電力削減に貢献
TEXT BY MATT BURGESS
TRANSLATION BY SATOMI FUJIWARA/GALILEO
WIRED (UK)
2016.07.22 FRI 17:00
ありがとうございました。
株式会社ラック





本資料は2016年06月現在の情報に基づいて作成しており、記載内容は予告なく変更される場合があります。
本資料に掲載の図は、資料作成用のイメージカットであり、実際とは異なる場合があります。
本資料は、弊社が提供するサービスや製品などの導入検討のためにご利用いただき、他の目的のためには利用しないようご注意ください。
LAC、ラック、JSOC、サイバー救急センターは株式会社ラックの登録商標です。
その他記載されている会社名、製品名は一般に各社の商標または登録商標です。
〒102-0093 東京都千代田区平河町2-16-1
平河町森タワー
Tel 03-6757-0113 Fax 03-6757-0193
sales@lac.co.jp
www.lac.co.jp
Copyright ©LAC Co., Ltd. All Rights Reserved.

他のカテゴリから探す

IT業界の改革にご協力いただけませんか?

本サイトは、株式会社オープンソース活用研究所がプロデュースする、中小IT企業による”本気”の情報提供セミナー「マジセミ」の結果レポートページです。「マジセミ」は、次を目的として活動しています。

我々はITエンジニアが、今よりももっと「誇り」と「喜び」をもって仕事をし、今よりももっと企業や社会に貢献できる、そんなIT業界を創りたいと考えています。

そのためには、技術をもった中小のIT企業がもっと元気になる必要がある。その為には、技術をもった中小のIT企業を、もっと皆様に知って頂く必要がある、と考えました。

株式会社オープンソース活用研究所
代表取締役所長 寺田雄一

本当かウソか、あなたが見極めてください。

もし、我々のこの活動にご賛同していただけるのであれば、ぜひ下のセミナーに参加してください。

「なんだ、結局ただの売り込みセミナーじゃないか」

もしそう感じたら、アンケートなり、あなたのFacebookなりに、そのままお書き頂き、拡散して頂いて構いません。

参加者からのお褒めの言葉、お叱りの言葉が、我々中小IT企業を成長させ、それが日本のIT業界を変えていくのだと、強く確信しています。

あなたの行動が、日本のIT業界を変えるのです。

日程を確認していただき、ご興味のあるセミナータイトルをクリックしてください。

「マジセミ」のFacebookページ

今後のセミナー情報などを提供させていただきたますので、「マジセミ」のFacebookページに「いいね!」をお願いします。

日本のIT業界を変えるためのアクション、ありがとうございました!

関連するセミナーの講演資料
「Webシステムにおける性能問題の原因調査」の難しさと、その対策について 失敗例から見る、JUnitによる単体テストの課題と、工数削減の方法~Jtestとは~ B2C、B2B向けWebサービスにおける認証基盤のあり方 ~便利と安全を両立させる認証・認可と、その最新技術~ OSSの監視ツール、本当にZabbixだけでよいのか? ~CactiやIcinga2など、他のOSS監視ツールが適しているケースとは~ RPAだけでは自動化できない業務を、どう効率化すればよいのか? ~Robochestrationという考え方について~ システム運用の効率化と、Zabbixによるクラウド環境、コンテナ環境の監視 【大阪開催】情シスアンケートから見たワークフロー製品の課題解説と、ワークフロー製品リプレースのポイント ~「2重入力」「連携できない」を解決する方法/他社製品からの移行ポイント~ 稼働管理超過で失敗しない、Redmineによるプロジェクト管理方法とは ~Redmineに、グローバル・ガントチャートや稼働時間管理の機能を追加~ 【東京開催】情シスアンケートから見たワークフロー製品の課題解説と、ワークフロー製品リプレースのポイント ~「2重入力」「連携できない」を解決する方法/他社製品からの移行ポイント~ なぜ、Webシステムの性能問題の原因調査は難しいのか?