DMMはECサービスや動画サービス、はたまた英会話サービスまでいろいろ手広くやられているサービスです。古い情報にはなりますが、そのDMMがシステム監視において基本としている5つの考えがあるという情報があったのでまとめておきます。
概要）
P56より、DMM.comの監視ノウハウの記事にて
●基本的に5つの監視の考え方で構成されている模様。
・死活監視
→Pingによる監視
・リソース監視
→CPU使用率、メモリ使用率、ディスク使用率、ロードアベレージ、
SWAPは必ず監視。閾値を超えたら、アラート。
・サービス監視
→URLにアクセスして正常か確認
・ポート監視
→該当ポートにアクセスできるか確認
・トラフィック監視
→SWやルータの監視
●アラートのレベル分けとタスク化
→DMMくらいの規模だと大小問わなければ、多くのアラームがある。レベル毎に分けて必要な行動を迅速にとれるように、計画をしている。
上記の５つの監視とそのアラート情報のレベル分けは、どのシステム監視でもやるべきなんでしょうね～
少し前になりますが、洗濯機が壊れた時にコインランドリーいった際にハイアールブンランドのAQUAが多く導入されてました。１回使った後、意識的にコインランドリー見るようになってチラ見してみると、他の店舗（チェーン店も違う）でもAQUAが導入されていて、強いブランドになってきたなと思ってました。
そんな所でインタビュー載っていたので気になった事書いていこうと思います。
概要
・AQUAはコインランドリー事業の7割シェア、ポイントはIoTによる効率的管理。
背景：３００店舗くらい運営している事業者だと、管理人は200人必要だった。
（機器チェック、モニタリング、メンテナンス、問い合わせサポート等）
それを、２０人だけで保守・管理可能になった。
・BtoCは新たなビジネスモデルとデザインが差別化のポイント
何かデータ解析したい時に、生データが表記ゆれしてしまう事あるかと思います。
名称が違えば、半角全角違いなどで、同じデータでも違うように見えてしまう事あるかと思います。
ルールを統一しておきたいと思いますが、ならそのルールのルールは何かないかと調べてみたところ、政府が公表しているのがあったのでここに記しておきたいと思います。
概要）
行政基本情報データ連携モデル標準ガイドライン「日付及び時刻」
日付、時刻、期間、時間帯、期間、季節など、それぞれどのように入力すべきか、ルールが記載されています。
例、全部書くと発散するので、最初の方だけ
１.１ 日付
日付のデータは以下の形式とする。半角を使用する。
YYYY-MM-DD
YYYY：西暦年 4 桁
MM ：月 2 桁（1 桁の場合には前に 0 をつける）
DD ：日 2 桁（1 桁の場合には前に 0 をつける）
例）2017-09-01
１.２ 曜日
曜日のコード及びデータは、以下のとおりとする。
1:月曜日
2:火曜日
3:水曜日
4:木曜日
5:金曜日
6:土曜日
7:日曜日
あと、わかりやすく参考になりやすい所は各冒頭ですね。こうすべしという所が記載されている所。
期間は、「開始日」、「終了日」と「開始時刻」、「終了時刻」の４つのデータ項目で設定することが望ましい。
（中略）
日付及び時刻に関して、「金曜日は 17 時まで」等の特記事項を記載する場合
には、上記のデータ項目内に記述するのではなく「備考」のデータ項目を付加し対応する。
もし、新たに集めるべきデータがあるのであれば、このようなルールに従って作成しておくと、フリーソフトやライブラリなどに食わせやすくなるかもしれませんね。
AWSでも勿論万能ではないんですよね、複数リージョン化しておかないとダメですね。
原因は冷却システムの電源トラブルみたいですね。物理インフラ故障はなかなか避けられないですね・・・
子供の頃は公衆電話使ってましたが、今はもう携帯電話の時代ですよね。駅やホテルで昔設置されていたであろう、机があるが特に椅子がないスペース（入口の横付近）が、よくあるかと思います。
携帯電話の料金でユニバーサル料金として数円とられていますが、徐々に減っていく方向性になりそうですね。
概要
・総務省検討会より、「社会経済環境の変化に対応した公衆電話の在り方について」
https://www.soumu.go.jp/main_content/000729480.pdf
検討理由）
第一種公衆電話は、最低限の通信手段を確保する観点から、ユニバーサルサービス（基礎的電気通信役務）として設置基準や補填の考え方を維持してきている。
モバイル通信の普及、人口減少や自然災害の頻発等、環境が急速に変化してきており、これまでの社会経済環境を前提とした公衆電話の在り方についても見直しが急務
公衆電話のコストも載ってますね（端末が75%と大部分占めるんですね）
何をもって、アメリカ～韓国までを選んだかはわかりませんが、、、韓国を除いた諸外国よりは現状でも手厚い（邪推すれば、だからもっと台数減すべき？）というデータですかね。
スケジュールとしては、月１回くらい検討会して６月末に結論を出すって所ですかね。
正直使いませんが、じゃあ撤去しますと言われると複雑な気分ですね。
セキュリティは大事ですよね。某ゲーム会社がランサムウェアで情報流出受けたり、某携帯会社口座が不正侵入されたり、セキュリティの脅威は日々高まります。
その中で今年の新たな脅威として、テレワーク狙いの攻撃が新たな上位の攻撃となったみたいです。
２月下旬に詳細が発表されるみたいなので、またウォッチしていきたいと思います。
航空開発は非常に長い期間がかかるので、市場変化したり、人材が入れ替わってマネジメントが非常に大変なみたいです。
読んでできになったポイントを残しておきたいと思います。
ポイント
・人材が入れ替わり、先代と同じような所でつまる。
人材の新陳代謝が起こり、経験が少ない若い人が開発すると、壁にぶつかる事が間々ある。そして、それは前の世代でも起こっていた事。技術継承が難しい上、シビアな安全管理が求められるため、トライアンドエラーも難しくノウハウがたまりにくい。
・コンコルドはビジネス的にペイしない。
超高速、ニューヨークとロンドンが３時間（通常7時間～8時間）というキャッチコピーで熱量は高いが、安全面や経済面でわりにあわずダメだった。
・ガードナのパイプサイクル
技術の登場から期待されて、一度期待先行ながらも実用足らずで失望されるフェーズがあるとの事。失望フェーズからの徐々に慣れてきて実用フェーズになるみたいです。
