Updated at 2023-06-01 11:55
越川 直人
Update post.
Updated by ppworks 2018-04-24 10:38:49 +0900

この文書は、esa LLC(以降、当社と呼ぶ)の運営する、esa.ioの運用に関してのポリシーである。

サービス運用責任者

  • 深谷篤生

サービス運用に関する通知手段

サービス全般の通知手段

監視における異常状況の通知手段

その他状況の通知手段

サービス運用監視

運用監視通知の段階

運用監視通知は以下の2段階で行う。

  • 速報としての通知
  • 速報をフォローアップする続報としての通知

フォローアップする続報は、速報の通知から追加情報が判明し次第、速報から30分~1時間程度を目標として通知する。

障害監視

サービスの提供に用いるアプリケーション、プラットフォーム、サーバ、ストレージ、ネットワークの正常動作監視を行い、障害を検知した場合には、利用者へ30分以内を目標に速報として通知する。

パフォーマンス監視

サービスの提供に用いるアプリケーション、プラットフォーム、サーバ、ストレージ、ネットワークに対し一定間隔でパフォーマンス監視を行い、パフォーマンス異常を検知した場合には、利用者へ30分以内を目標に速報として通知する。

監視結果報告

サービスの提供に用いるアプリケーション、プラットフォーム、サーバ・ストレージ等の障害監視、パフォーマンス監視等の結果をslackを通してサービス運用責任者が確認できるようにしている。

監視手段

  • AWS CloudWatch
  • New Relic
  • Papertrail
  • Bugsnag
  • Pingdom

サービス変更通知

サービスの大規模な変更が発生する場合の通知

1週間前程度を目標に利用者へ通知する。

サービスの停止が発生する場合の通知

1週間前に利用者へ通知する。

サービスの提供が終了する場合の通知

3ヶ月前に利用者へ通知する。

SLA

SLAとしての保証は設けない。

サービス稼働率

目標

年間99%稼働を目標としている。

過去の稼働率は、https://status.esa.io/uptime を参照。

RTO(Recovery Time Objective)

サービス停止時の目標普及時間は1時間を目標値とする。

RPO(Recovery Point Objective)

システム障害などでデータが損壊した際に、復旧するバックアップデータは最大でも24時間前とする。

メール送信

メール送信は

  • システム内の通知
  • ユーザーからのフィードバック返信
  • 監視における異常状況の通知

等で行う。

メール送信時のポリシー

  • 送信されるメールのToまたはCcに複数ユーザのメールアドレスを含めない。
  • SaaS(mandrill)にてReturn-pathを適切に設定している。
  • エラーにより配送できなかったユーザのアドレスは、SaaS 側で再送信を防いでいる。
  • ユーザー設定ページ(/user/settings) より受信拒否が可能。
  • メール送信時の内容に機密事項は含めていない。

預託データの取扱

預託データの権利は、利用者企業に帰属する。

預託データの返還

チームの管理者用設定ページ(/team/admin) より、預託データをエクスポート可能である。

預託データの削除

サービス終了時、預託データを削除する。

インフラ情報

サービスの提供に用いるアプリケーション、プラットフォーム、サーバ・ストレージ等(情報セキュリティ対策機器、通信機器等)の情報を示す。

ネットワーク構成

アクセス管理

AWSのIAMを利用して、PASSWORD認証は使わずに公開鍵認証方式でのアクセスとする。

外部および内部からの不正アクセスを防止する措置

ELBの設定を適切に行っている。

時刻同期

サービスの提供に用いるアプリケーション、プラットフォーム、サーバ・ストレージ等(情報セキュリティ対策機器、通信機器等)の時刻同期の方法をntpdを用いた時刻同期を行うことで、正確な時刻同期を担保している。

構成管理

サービスの提供に用いるプラットフォーム、サーバ・ストレージ、情報セキュリティ対策機器、通信機器について、利用しているソフトウェアやファームウェアのバージョン管理、ハードウェアの構成管理はソースコード化して、GitHub上で管理しており、定期的に見直しを行っている。

セキュリティパッチ

サービスの提供に用いるプラットフォーム、サーバ・ストレージ、情報セキュリティ対策機器、通信機器についての技術的脆弱性に関する情報(OS、その他ソフトウェアのパッチ発行情報等)を定期的に収集し、随時パッチによる更新を12時間~3日程度以内を目標に行っている。

ディザスタリカバリ対策

災害時や障害時のデータ保持のため、データベースに関して、AWSのマルチAZ(Availability Zone)で担保している。

キャパシティプランニング

サービスの提供に用いるアプリケーション、プラットフォーム、サーバ・ストレージに対し、利用者の利用状況の予測に基づいて容量・能力等を設計し、定期的に見直しを行う。

ログの保管

利用者の利用状況、例外処理、情報セキュリティ事象の記録(ログ等)を取得した記録は、Papertailにて、1年間保持する。

ログの開示

必要に応じて利用者へログの開示を行う。

構成の変更承認

サービス運用責任者の承認を必要とする。

データの暗号化

DBMSの機能を用いてデータを暗号化して保存している。

データの保護

データを暗号化するためのキーやパスワードは限られた管理者によって管理されている。

データのバックアップ

AWSのS3にて保管。

サービス運用に関わるセキュリティポリシー

サービス運用に関わるセキュリティポリシー関しては、セキュリティーポリシーの項を設ける。

この文書は、esa LLC(以降、当社と呼ぶ)の運営する、[esa.io](https://esa.io)の運用に関してのポリシーである。

# サービス運用責任者

* 深谷篤生

# サービス運用に関する通知手段

## サービス全般の通知手段

* ドキュメントページ [docs.esa.io](https://docs.esa.io)への記載
* [Twitterのesa公式アカウント](https://twitter.com/esa_io)からの発信

## 監視における異常状況の通知手段

* ドキュメントページ [docs.esa.io](https://docs.esa.io)への記載
* [Twitterのesa公式アカウント](https://twitter.com/esa_io)からの発信
* 利用者が登録したメール宛への配信

## その他状況の通知手段

* ステータス通知用サイト [status.esa.io](http://status.esa.io/)にて通知

# サービス運用監視

## 運用監視通知の段階

運用監視通知は以下の2段階で行う。

* 速報としての通知
* 速報をフォローアップする続報としての通知

フォローアップする続報は、速報の通知から追加情報が判明し次第、速報から**30分~1時間程度**を目標として通知する。

## 障害監視

サービスの提供に用いるアプリケーション、プラットフォーム、サーバ、ストレージ、ネットワークの正常動作監視を行い、障害を検知した場合には、利用者へ**30分**以内を目標に速報として通知する。

<!-- 対応予定

## 不正アクセス監視

サービスの提供に用いるアプリケーション、プラットフォーム、サーバ、ストレージ、ネットワークへの不正アクセス監視を行い、不正アクセスを検知した場合には、利用者へ**30分**以内を目標に速報として通知する。

<div  style="border: 1px solid #666;padding:10px;margin:10px;background: #ffffee;">
対応予定
</div>

 -->

## パフォーマンス監視

サービスの提供に用いるアプリケーション、プラットフォーム、サーバ、ストレージ、ネットワークに対し一定間隔でパフォーマンス監視を行い、パフォーマンス異常を検知した場合には、利用者へ**30分**以内を目標に速報として通知する。

## 監視結果報告

サービスの提供に用いるアプリケーション、プラットフォーム、サーバ・ストレージ等の障害監視、パフォーマンス監視等の結果をslackを通してサービス運用責任者が確認できるようにしている。

## 監視手段

* AWS CloudWatch
* New Relic
* Papertrail
* Bugsnag
* Pingdom

# サービス変更通知

## サービスの大規模な変更が発生する場合の通知

**1週間前程度**を目標に利用者へ通知する。

## サービスの停止が発生する場合の通知

**1週間前**に利用者へ通知する。

## サービスの提供が終了する場合の通知

**3ヶ月前**に利用者へ通知する。

# SLA

SLAとしての保証は設けない。

# サービス稼働率

## 目標

年間99%稼働を目標としている。

過去の稼働率は、https://status.esa.io/uptime を参照。

## RTO(Recovery Time Objective)

サービス停止時の目標普及時間は**1時間**を目標値とする。

## RPO(Recovery Point Objective)

システム障害などでデータが損壊した際に、復旧するバックアップデータは最大でも**24時間前**とする。

# メール送信

メール送信は

* システム内の通知
* ユーザーからのフィードバック返信
* 監視における異常状況の通知

等で行う。

## メール送信時のポリシー

* 送信されるメールのToまたはCcに複数ユーザのメールアドレスを含めない。
* SaaS(mandrill)にてReturn-pathを適切に設定している。
* エラーにより配送できなかったユーザのアドレスは、SaaS 側で再送信を防いでいる。
* ユーザー設定ページ(/user/settings) より受信拒否が可能。
* メール送信時の内容に機密事項は含めていない。

# 預託データの取扱

預託データの権利は、利用者企業に帰属する。

## 預託データの返還

チームの管理者用設定ページ(/team/admin) より、預託データをエクスポート可能である。

## 預託データの削除

サービス終了時、預託データを削除する。

# インフラ情報

サービスの提供に用いるアプリケーション、プラットフォーム、サーバ・ストレージ等(情報セキュリティ対策機器、通信機器等)の情報を示す。

## ネットワーク構成

![](https://img.esa.io/uploads/production/attachments/3/2017/09/25/2/8e17d0a5-e4c4-4aab-aa92-b14b5acf0820.png)

## アクセス管理

AWSのIAMを利用して、PASSWORD認証は使わずに公開鍵認証方式でのアクセスとする。

## 外部および内部からの不正アクセスを防止する措置

ELBの設定を適切に行っている。

## 時刻同期

サービスの提供に用いるアプリケーション、プラットフォーム、サーバ・ストレージ等(情報セキュリティ対策機器、通信機器等)の時刻同期の方法をntpdを用いた時刻同期を行うことで、正確な時刻同期を担保している。


## 構成管理

サービスの提供に用いるプラットフォーム、サーバ・ストレージ、情報セキュリティ対策機器、通信機器について、利用しているソフトウェアやファームウェアのバージョン管理、ハードウェアの構成管理はソースコード化して、GitHub上で管理しており、定期的に見直しを行っている。

## セキュリティパッチ

サービスの提供に用いるプラットフォーム、サーバ・ストレージ、情報セキュリティ対策機器、通信機器についての技術的脆弱性に関する情報(OS、その他ソフトウェアのパッチ発行情報等)を定期的に収集し、随時パッチによる更新を**12時間~3日程度**以内を目標に行っている。

## ディザスタリカバリ対策

災害時や障害時のデータ保持のため、データベースに関して、AWSのマルチAZ(Availability Zone)で担保している。

## キャパシティプランニング

サービスの提供に用いるアプリケーション、プラットフォーム、サーバ・ストレージに対し、利用者の利用状況の予測に基づいて容量・能力等を設計し、定期的に見直しを行う。

## ログの保管

利用者の利用状況、例外処理、情報セキュリティ事象の記録(ログ等)を取得した記録は、Papertailにて、**1年間保持**する。



## ログの開示

必要に応じて利用者へログの開示を行う。

## 構成の変更承認

サービス運用責任者の承認を必要とする。

## データの暗号化

DBMSの機能を用いてデータを暗号化して保存している。

## データの保護

データを暗号化するためのキーやパスワードは限られた管理者によって管理されている。

## データのバックアップ

AWSのS3にて保管。

# サービス運用に関わるセキュリティポリシー

サービス運用に関わるセキュリティポリシー関しては、[セキュリティーポリシーの項を設ける。](https://docs.esa.io/posts/260#%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E9%81%8B%E7%94%A8%E3%81%AB%E9%96%A2%E3%82%8F%E3%82%8B%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%83%9D%E3%83%AA%E3%82%B7%E3%83%BC)

この文書は、esa LLC(以降、当社と呼ぶ)の運営する、esa.ioの運用に関してのポリシーである。

サービス運用責任者

  • 深谷篤生

サービス運用に関する通知手段

サービス全般の通知手段

監視における異常状況の通知手段

その他状況の通知手段

サービス運用監視

運用監視通知の段階

運用監視通知は以下の2段階で行う。

  • 速報としての通知
  • 速報をフォローアップする続報としての通知

フォローアップする続報は、速報の通知から追加情報が判明し次第、速報から30分~1時間程度を目標として通知する。

障害監視

サービスの提供に用いるアプリケーション、プラットフォーム、サーバ、ストレージ、ネットワークの正常動作監視を行い、障害を検知した場合には、利用者へ30分以内を目標に速報として通知する。

パフォーマンス監視

サービスの提供に用いるアプリケーション、プラットフォーム、サーバ、ストレージ、ネットワークに対し一定間隔でパフォーマンス監視を行い、パフォーマンス異常を検知した場合には、利用者へ30分以内を目標に速報として通知する。

監視結果報告

サービスの提供に用いるアプリケーション、プラットフォーム、サーバ・ストレージ等の障害監視、パフォーマンス監視等の結果をslackを通してサービス運用責任者が確認できるようにしている。

監視手段

  • AWS CloudWatch
  • New Relic
  • Papertrail
  • Bugsnag
  • Pingdom

サービス変更通知

サービスの大規模な変更が発生する場合の通知

1週間前程度を目標に利用者へ通知する。

サービスの停止が発生する場合の通知

1週間前に利用者へ通知する。

サービスの提供が終了する場合の通知

3ヶ月前に利用者へ通知する。

SLA

SLAとしての保証は設けない。

サービス稼働率

目標

年間99%稼働を目標としている。

過去の稼働率は、https://status.esa.io/uptime を参照。

RTO(Recovery Time Objective)

サービス停止時の目標普及時間は1時間を目標値とする。

RPO(Recovery Point Objective)

システム障害などでデータが損壊した際に、復旧するバックアップデータは最大でも24時間前とする。

メール送信

メール送信は

  • システム内の通知
  • ユーザーからのフィードバック返信
  • 監視における異常状況の通知

等で行う。

メール送信時のポリシー

  • 送信されるメールのToまたはCcに複数ユーザのメールアドレスを含めない。
  • SaaS(mandrill)にてReturn-pathを適切に設定している。
  • エラーにより配送できなかったユーザのアドレスは、SaaS 側で再送信を防いでいる。
  • ユーザー設定ページ(/user/settings) より受信拒否が可能。
  • メール送信時の内容に機密事項は含めていない。

預託データの取扱

預託データの権利は、利用者企業に帰属する。

預託データの返還

チームの管理者用設定ページ(/team/admin) より、預託データをエクスポート可能である。

預託データの削除

サービス終了時、預託データを削除する。

インフラ情報

サービスの提供に用いるアプリケーション、プラットフォーム、サーバ・ストレージ等(情報セキュリティ対策機器、通信機器等)の情報を示す。

ネットワーク構成

アクセス管理

AWSのIAMを利用して、PASSWORD認証は使わずに公開鍵認証方式でのアクセスとする。

外部および内部からの不正アクセスを防止する措置

ELBの設定を適切に行っている。

時刻同期

サービスの提供に用いるアプリケーション、プラットフォーム、サーバ・ストレージ等(情報セキュリティ対策機器、通信機器等)の時刻同期の方法をntpdを用いた時刻同期を行うことで、正確な時刻同期を担保している。

構成管理

サービスの提供に用いるプラットフォーム、サーバ・ストレージ、情報セキュリティ対策機器、通信機器について、利用しているソフトウェアやファームウェアのバージョン管理、ハードウェアの構成管理はソースコード化して、GitHub上で管理しており、定期的に見直しを行っている。

セキュリティパッチ

サービスの提供に用いるプラットフォーム、サーバ・ストレージ、情報セキュリティ対策機器、通信機器についての技術的脆弱性に関する情報(OS、その他ソフトウェアのパッチ発行情報等)を定期的に収集し、随時パッチによる更新を12時間~3日程度以内を目標に行っている。

ディザスタリカバリ対策

災害時や障害時のデータ保持のため、データベースに関して、AWSのマルチAZ(Availability Zone)で担保している。

キャパシティプランニング

サービスの提供に用いるアプリケーション、プラットフォーム、サーバ・ストレージに対し、利用者の利用状況の予測に基づいて容量・能力等を設計し、定期的に見直しを行う。

ログの保管

利用者の利用状況、例外処理、情報セキュリティ事象の記録(ログ等)を取得した記録は、Papertailにて、1年間保持する。

ログの開示

必要に応じて利用者へログの開示を行う。

構成の変更承認

サービス運用責任者の承認を必要とする。

データの暗号化

DBMSの機能を用いてデータを暗号化して保存している。

データの保護

データを暗号化するためのキーやパスワードは限られた管理者によって管理されている。

データのバックアップ

AWSのS3にて保管。

サービス運用に関わるセキュリティポリシー

サービス運用に関わるセキュリティポリシー関しては、セキュリティーポリシーの項を設ける。