S3にあるCloud Trailログを確認するため、Sumo Logicを利用してみた

S3にあるCloud Trailログを閲覧したく、CloudTrailのセキュリティ監視をちょー簡単にやってみた【Sumo Logic】 をやってみた。
詳細は上記URLに記載されているため、気になったことだけ記載する。

SumoLogicについて

・SaaS型のログ収集分析サービス
・無料版は1日500MBまでのアップロードが可能
 (データ保持期間は7日間、トータルで3.5GBまでのデータが保持可能、という情報も見つけたが公式ソースを見つけられなかった)
・[Sumo Logic Free]を選択した。他のプランは30日間無料でプロやエンタープライズの機能を利用可能(お金を払わなければそのまま無料版の機能を利用できそう)

構築内容

・SumoLogicのいうとおりにすれば設定が完了する
・CloudTrailのS3に権限を与えたIAMユーザを作成し、SumoLogicにアクセスキーを登録する

SumoLogicの設定

・過去のログがみたかったため、[Collection should begin]を[All Time]に変更した

・[App Catalog]にCloudTrailの閲覧用テンプレートが用意されているため、利用した

参考

[OpsJAWS: やってみようシリーズ] Sumologicの始め方

JULY TECH FESTA 2018 に参加した(2)

運用におけるシェルの役割とそのあり方を考える – 山下和彦 氏

資料:運用におけるシェルの役割とそのあり方を考える

GMOペポバのサービス – ロリポップレンタルサーバ

・秒間2万8千アクセス/秒(DoSを受けた際はこれ以上)
・ビーク8Gbps

Shellに対するいくつかの考察

・Shell = Shell Script (bashで記載されたものを表す)
・RedMonk社(StackOverflow・GitHubでの人気度)によると、言語としては12位くらい

Shellの特徴

・メリット
 ・パイプ、オプションを利用した強力な組み合わせ
 ・ほとんどの場合は導入コストが低い(インストールの手間なし、依存性なし)
・デメリット
 ・テスト実装、変化に強い実装、再利用性の高い実装は苦手

ライフサイクル観点からの考察

・パイプ、オプションが強力すぎて、熟練者でないと見にくいことがある
⇒開発効率化には最適であるが、複数人での運用保守には向いていない(運用の際に負債として残る可能性あり)
・携わるメンバがShellに詳しければ問題ないが、Shellに学習コストをかけるかというと、
 WEBエンジニアは覚えることが多くベターとは言えない

・例外として、USP研究所のようにShellに特化したユニケージ開発手法などが定着している場合もある
 ・RDBを利用せず、テキストファイルによってデータを管理

言語特性観点からの考察

・長期的な運用には不向き
・変化が少ない局面については有効
 ・バックアップスクリプト
 ・監視系スクリプト

なぜ人類はShellをかかなくなったのか?

・Infrastructure as CodeによってLLやGoを書き始めた
・自動化の高度化
 LLやGolangで簡単にプロセスができ、人が介在せずとも処理ができるようになったため
 処理を集めてjob.shとして実行することなどを、自動化と呼ぶ時代ではなくなった

それでもShellが好きな人も

・人は得意な言語で書くため、評価にも反映させる

なぜGolang?

・システムプログラミングに必要なAPIが一通りそろっている
・可搬性が高く、サーバに配置しやすい

まとめ

・長期運用するなら、Shellを頑張るよりも、他の言語で対応したほうが幸せになる

知らなかったこと

・shellcheckというshellの記法をチェックするようなツールもある

サーバーやNW機器の構成・設定管理に困ってませんか?簡単に最新状況が把握できるインベントリ収集ツールの紹介 – 船井 覚 氏

資料:サーバーやNW機器の構成・設定管理に困ってませんか?簡単に最新状況が把握できるインベントリ収集ツールの紹介

Open-Audit

・コミュニティ版と商用版がある
・20ノードまでは管理可能
・エージェントレス型
・SNMP,WMI,SSHでアクセスして、情報を取得する

できないこと

・収集のみ、設定変更はできない
・時系列での履歴管理
・インデント管理、資産管理
⇒OpenPIEを利用すればできるように

OCS Inventory NG

・エージェント型
・コミュニティ版のみ

JULY TECH FESTA 2018 に参加した(1)

ノウハウ丸ごと共有します!ハートビーツの24/365体制を支える人材育成 – 倉持亘 氏

感想

・主体性(自分で考える)を大切にしている
・手を動かさないと身につかない
・障害時に大外ししないことを意識する
に共感した。

24/365を支える体制

・3交代制であり、3チームでローテーションしている
・1チーム5-6人で、役割がある(主担当と副担当、研修生)

目指す人物像

・なぜそうなるかを理解できる。自分で理解して、答えにたどり着ける人材(原則原理)
・技術はツールであり、このツールを利用して顧客へ価値を与えられる
・迅速に復旧までたどり着ける

人材育成におけるテーマ

・主体性
 自分で考えさせる。座学よりも、手を動かして理解してもらう(でなければ身につかない)

研修内容

研修生

・未経験者も雇うため、サーバ構築から障害対応までの基礎を教育する

サーバ構築研修

・目的:LAMP環境の仕組みを理解する
・タワーPCを渡して、あとはよろしく!チェックポイントは提示するが、構築の手順は提示しない
・やっていいこと、悪いことを学ぶ
・たくさん失敗させて、たくさん学んでもらう
・質問に対して、答えを伝えるのではなく、なるべく本人が答えにたどり着くように誘導する
・やったことはBacklogにエビデンスとして残してもらう
 ・後で担当者が方向性があっているか確認する
 ・ググってコピペしたものではないか確認するようにしている(自分の言葉でかけているか)

ロールプレイング研修

・目的:以下を身につけてもらう
 ・技術だけでは顧客に価値を提供できない
 ・技術がないと仕事はできない、
・顧客とHBのエンジニアという設定でロールプレイング
 顧客からアバウトな相談事を受けて、必要な情報を聞き取り、顧客の解決策を検討し、プレゼンしてもらう
・チェックポイント
 ・Quick & Dirty (完ぺきではないが素早く)を実践できているか
 ・顧客を理解できているか(サービスの理解、ビジネスの理解)
 ・技術的に正しいことを言っており、もし不明瞭なことがあった場合に持ち帰っているか

障害対応研修&実践

・障害対応フローを覚える
・調査コマンドを課題ベースで覚えてもらう
 使い方の詳細は説明しない。後ほど理解できているか確認する
・座学で学んだことを実際の障害で対応してもらう

フィードバック

・現場ではうまくいかないことも多いため、フィードバックを実施している
 ・その場でのフィードバック
 ・Backlogを利用したフィードバック
  目的:振り返る機会を作る、指導者と研修生の認識をなくす
  日報のようなものに、わからないことなどを記載してもらい、後日認識合わせをする
 ・KPTを使った振り返り
  ・P(自分に足りないところ):指導者の考えるPと研修生の考えるPのギャップを埋める
  ・T(Pをどうやって身につけるか):なるべく自分で考えさせる
  ・隔週実施

副担当

主担当面談

・主担当とは:シフト内の障害対応の責任者、すべての障害に目を通し、副担当に仕事を割り振る役割
・目的:主担当に必要なスキルを身につける
 ・主担当のロールプレイング
  ・災害時のロールプレイング
  ・複数障害が発生した場合のロールプレイング
   ・面談してフローを作成していくイメージ
   ・チェックポイントとしては、優先順位をつけて、正しく仕事を割り振れるか、
   ・論理的に切り分けて大外しせずに復旧までたどり着けるか

育成の課題

・指導者への指導
 人によって教え方が上手、下手がある
・フィードバックする時間の確保
 日頃の業務の中でフィードバックする時間がないときがある

質疑応答

・障害でパニックになる人に対してどうしているか?
⇒自分に自信がないことが原因だと思うため、小さい成功体験を積み重ねるよう教育している

・自分はできている思っている主担当に対してどのようにアプローチしているか?
⇒IT業界は流れが早いため、別途研修を設けている

「使ってみた」では終わらせない! AWS GuardDutyを使ったサイバー攻撃の検出・分析45分スタートアップ講座 – 鈴木研吾 氏

資料:GuardDutyを使ったサイバー攻撃の検出と分析.pdf

感想 – というよりも知らなかったこと

・ArcSight、SplunkといったSIEMツールがある
・サイバーキルチェーンという標的型攻撃における攻撃手順を標準化したものがある
 これをもとに多段防御を検討することができる

GuardDuty 素晴らしいところ

・GuardDutyは検知だけのため、システム的な影響なし
 内部ではログをコピーして分析するため、遅延が発生することはない
 中の人に聞いた時も、ただただONにするだけでよいとのこと
・金銭面への影響についても、1ヵ月でどれくらいかかるかチェック可能

なぜGuardDuty

・AWSでは想定すべき脅威の種類が増えて、今までの検知ロジックだけでは不足している
 今までの検知が古いというわけではない

オンプレミス時代にはなかった想定すべき脅威の種類

・クラウドサービスとしてのアカウント
・リソースと権限
・動的にスケールするリソース
・Pay as you Goなリソース

GuardDuty in Folio

いくらかかっている?

・11アカウント全てON、$6.38/day
・SOCサービスは月間20万円ほど

誤検知ある?

・とても少ない
・もし誤検知があれば、その条件のアラートを無効にする機能が最近リリースされた

ユースケース?

・GuardDutyは集約する機能しかもたないため、CloudwatchからLambdaに流している
・検知したら、自動的にスナップショットを取得し、別VPCに展開し、フォレンジックするような仕組みを用意することも可能

Docker入門

今更ですが、、Dockerの基本的なことをまとめる。

Dockerとは

Dockerが必要となった背景

・アプリケーションは作ったら終わりではなく、ユーザの要望を取り込み価値のあるアプリケーションに改善していく必要がある
・ユーザ要望が多様化し、変化のスピードも早くなっているため、迅速かつ柔軟なIT基盤が求められるようになってきた
・継続的インテグレーション時の仮想マシンでの問題を、Dockerは解決できる

特徴

・アプリケーションの実行環境をコード管理できる
 ・アプリケーション開発者も環境をすぐに用意することができる
  (サーバ管理者にサーバ構築してもらう必要がなくなる)
 ・本番環境に追加した設定がテスト環境には追加されていない、を回避しやすくなる
・ベースOSのカーネルや機能を利用するため、仮想マシンと比較してオーバーヘッドが少なくなり、リソース消費量(メモリやディスク容量)が少なくなる
 ・作業が効率化される(構築時間がとても早くなる)
 ・仮想マシンとは違って、ハードウェアやカーネルに影響するアプリケーションは利用できない場合がある

操作方法

Docker for Windows で操作する。
まずは、windows10へのdockerインストールにしたがって、Dockerをインストールした。

ubuntuにnginxをインストールして、ブラウザで閲覧できるようにする

### Dockerレジストリ(リポジトリ)から、コンテナイメージを検索する ###
### 公式で、ubuntuを含むコンテナイメージを検索している ###
> docker search --no-trunc --filter is-official=true ubuntu
NAME                 DESCRIPTION                                                                                            STARS               OFFICIAL            AUTOMATED
ubuntu               Ubuntu is a Debian-based Linux operating system based on free software.                                7991                [OK]
ubuntu-upstart       Upstart is an event-based replacement for the /sbin/init daemon which starts processes at boot         87                  [OK]
neurodebian          NeuroDebian provides neuroscience research software for Debian, Ubuntu, and other derivatives.         50                  [OK]
ubuntu-debootstrap   debootstrap --variant=minbase --components=main,universe --include=inetutils-ping,iproute2 <suite> /   39                  [OK]

### コンテナイメージをダウンロードする ###
### ubuntuの最新バージョンをダウンロードする ###
### もしDockerホストのubuntuのバージョンが古くても、Linuxカーネルは後方互換性があるため基本的には問題ない ###
> docker pull ubuntu
Using default tag: latest
latest: Pulling from library/ubuntu
6b98dfc16071: Pull complete
4001a1209541: Pull complete
6319fc68c576: Pull complete
b24603670dc3: Pull complete
97f170c87c6f: Pull complete
Digest: sha256:5f4bdc3467537cbbe563e80db2c3ec95d548a9145d64453b06939c4592d67b6d
Status: Downloaded newer image for ubuntu:latest

### ダウンロードしたコンテナイメージを表示する ###
> docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ubuntu              latest              113a43faa138        5 weeks ago         81.2MB

### Dockerコンテナを起動して、nginxをインストールする ###
### 最初にapt-get updateしないとエラーとなる ###

### docker run オプション ###
### -h hostname ホスト名を指定することが可能※デフォルトではコンテナIDと同じ名前となる ###
### --cpuset-cpus 0-3 --memory 4096m などで利用するCPUやメモリ数を指定することが可能 ###
> docker run -it --name ubuntu-container ubuntu
root@b6ec500d4fd7:/# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04 LTS"

root@b6ec500d4fd7:/# apt-get install nginx
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package nginx

root@b6ec500d4fd7:/# apt-get update && apt-get upgrade
...

root@b6ec500d4fd7:/# apt-get install nginx
...
root@b6ec500d4fd7:/# /etc/init.d/nginx status
 * nginx is not running

root@b6ec500d4fd7:/# /etc/init.d/nginx start
 * Starting nginx nginx                                                                                                                                                      [ OK ]

root@b6ec500d4fd7:/# ps afx
   PID TTY      STAT   TIME COMMAND
     1 pts/0    Ss     0:00 /bin/bash
   920 ?        Ss     0:00 nginx: master process /usr/sbin/nginx
   921 ?        S      0:00  \_ nginx: worker process
   922 ?        S      0:00  \_ nginx: worker process
   924 pts/0    R+     0:00 ps afx

root@b6ec500d4fd7:/# exit
exit

### コンテナイメージを作成する ###
> docker commit ubuntu-container akatuki/ubuntu-nginx
sha256:507f4bf357e5a0bcb5df74d50e51fea31778fcc6f0f17938baf977aeb6db38d0

> docker images
REPOSITORY             TAG                 IMAGE ID            CREATED             SIZE
akatuki/ubuntu-nginx   latest              507f4bf357e5        5 seconds ago       196MB
ubuntu                 latest              113a43faa138        5 weeks ago         81.2MB

### 80番ポートを利用してコンテナを起動する ###
> docker run -itd -p 80:80 --name ubuntu-nginx-container akatuki/ubuntu-nginx

> docker ps
CONTAINER ID        IMAGE                  COMMAND             CREATED             STATUS              PORTS                NAMES
76c54b34974b        akatuki/ubuntu-nginx   "/bin/bash"         29 seconds ago      Up 27 seconds       0.0.0.0:80->80/tcp   ubuntu-nginx-container

> docker attach ubuntu-nginx-container

root@76c54b34974b:/# /etc/init.d/nginx start
 * Starting nginx nginx

### [Ctl]+[P]+[Q]でコンテナを終了せずに、PowerShellに戻ることが可能 ###
### exitするとPID1の /bin/bash が終了する、つまりコンテナが終了する ###
root@76c54b34974b:/# read escape sequence

localhostにアクセスすると、nginxのページが表示される。

Dockerfileを利用した場合

# Dockerfile

FROM ubuntu
MAINTAINER akatuki

RUN apt-get update && apt-get upgrade && apt-get install nginx
CMD service nginx start && bash
> docker build -t akatuki/ubuntu-nginx-2 .\docker_ubuntu_nginx\
Sending build context to Docker daemon  2.048kB
Step 1/4 : FROM ubuntu
 ---> 113a43faa138
Step 2/4 : MAINTAINER akatuki
 ---> Running in 16fcf202048b
Removing intermediate container 16fcf202048b
 ---> 216a90a83370
Step 3/4 : RUN apt-get update && apt-get -y upgrade && apt-get install -y nginx
 ---> Running in 33c5c837b636
...
Removing intermediate container 33c5c837b636
 ---> 3e4fc279fc09
Step 4/4 : CMD service nginx start && bash
 ---> Running in f71c691629b7
Removing intermediate container f71c691629b7
 ---> 1bae7466b72c
Successfully built 1bae7466b72c
Successfully tagged akatuki/ubuntu-nginx-2:latest
SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directories added to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories.

> docker images
REPOSITORY               TAG                 IMAGE ID            CREATED              SIZE
akatuki/ubuntu-nginx-2   latest              1bae7466b72c        About a minute ago   194MB

> docker run -itd -p 80:80 --name ubuntu-nginx-container-2 akatuki/ubuntu-nginx-2

その他便利なコマンド

### dockerのバージョンを確認する ###
> docker version
Client:
 Version:      18.03.1-ce
 API version:  1.37
 Go version:   go1.9.5
 Git commit:   9ee9f40
 Built:        Thu Apr 26 07:12:48 2018
 OS/Arch:      windows/amd64
 Experimental: false
 Orchestrator: swarm

Server:
 Engine:
  Version:      18.03.1-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.5
  Git commit:   9ee9f40
  Built:        Thu Apr 26 07:22:38 2018
  OS/Arch:      linux/amd64
  Experimental: true

### docker実行環境を確認する ###
> docker info
Containers: 2
 Running: 1
 Paused: 0
 Stopped: 1
Images: 2
Server Version: 18.03.1-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 773c489c9c1b21a6d78b5c538cd395416ec50f88
runc version: 4fc53a81fb7c994640722ac585fa9ca548971871
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.87-linuxkit-aufs
Operating System: Docker for Windows
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.934GiB
Name: linuxkit-00155d011c1d
ID: IHML:MLXN:VWM4:BN3Q:QYWT:QJC4:QVAO:UD5Q:ZS3M:DQC7:2NVH:EP34
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 27
 Goroutines: 48
 System Time: 2018-07-16T14:06:28.8408325Z
 EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: true
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

### コンテナの詳細情報を取得する ###
> docker inspect ubuntu-nginx-container
[
    {
        "Id": "76c54b34974ba7c0cba4aade1875f280517e27588796b96831290386fc12e813",
        "Created": "2018-07-16T13:58:33.5983827Z",
        "Path": "/bin/bash",
        "Args": [],
...

### コンテナ内で変更があったディレクトリとファイルを表示する ###
> docker diff ubuntu-nginx-container
C /root/.bash_history
C /run/nginx.pid
C /var/log/nginx/access.log
C /var/log/nginx/error.log

### コンテナのプロセスを確認する ###
> docker top ubuntu-nginx-container
PID                 USER                TIME                COMMAND
14521               root                0:00                /bin/bash
14671               root                0:00                nginx: master process /usr/sbin/nginx
14672               xfs                 0:00                nginx: worker process
14673               xfs                 0:00                nginx: worker process

### コンテナ内部で実行された標準出力、標準エラー出力への内容を確認する ###
> docker logs ubuntu-nginx-container
root@76c54b34974b:/# /etc/init.d/nginx start
 * Starting nginx nginx

### コンテナイメージの中間イメージの履歴を表示する ###
> docker history akatuki/ubuntu-nginx
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
507f4bf357e5        30 minutes ago      /bin/bash                                       115MB
113a43faa138        5 weeks ago         /bin/sh -c #(nop)  CMD ["/bin/bash"]            0B
<missing>           5 weeks ago         /bin/sh -c mkdir -p /run/systemd && echo 'do…   7B
<missing>           5 weeks ago         /bin/sh -c sed -i 's/^#\s*\(deb.*universe\)$…   2.76kB
<missing>           5 weeks ago         /bin/sh -c rm -rf /var/lib/apt/lists/*          0B
<missing>           5 weeks ago         /bin/sh -c set -xe   && echo '#!/bin/sh' > /…   745B
<missing>           5 weeks ago         /bin/sh -c #(nop) ADD file:28c0771e44ff530db…   81.1MB

### コンテナを出力する ###
> docker export ubuntu-nginx-container > ubuntu-nginx-container.img

補足1 – コンテナ管理について

複数アプリケーション利用時のコンテナ数について

・アプリケーションごとにコンテナを分割がベストプラクティス
 ・コンテナを作り直す際に、設定変更内容が明確になるため

コンテナのスナップショット

・コンテナ起動時にスナップショットを作成する
 停止時はスナップショットを保持する
 削除時にスナップショットを削除する

補足2 – すべてのコンテナイメージを削除する

> docker rmi -f  $(docker images -aq)

参考

今、なぜ「Docker」なのか
Docker実践入門――Linuxコンテナ技術の基礎から応用まで
docker コマンド チートシート
docker初心者の方が知っておいた方がよい基礎知識
docker-compose upするとコンテナが一瞬でexited with code 1する話

Visual Studio Code のデフォルト設定変更

概要

以下を参考に、Visual Studio Code の設定を変更した。
VSCodeで文字コードを自動判別する
VS Codeのミニマップが邪魔なので消す
Visual Studio Codeでhtmlのプレビューを表示する

文字コードの自動判別をONにする

[ファイル] > [基本設定] > [設定] より、以下を追加した。

"files.autoGuessEncoding": true

左側の設定を[編集]することで、設定を追加することも可能。

ミニマップをOFFにする

右側にあるミニマップなるものが不要なため無効に。

"editor.minimap.enabled": false

HTMLファイルのライブプレビューをONにする

[Live HTML Previewer]をインストールする。

[Ctrl]+[q] → [s]にて、横にプレビュー画面が表示される。

Google流資料作成術を読んだ

Google流資料作成術を読んだ。その際のメモ。

第1章 – コンテキストを理解する

・誰に、何を、どのように伝えるかを明確にする

そのために

・自信のある態度で伝えること
 ・「相手は自分より多くのことを知り、どう行動するかは相手次第」と思い込んでいる人が多いがそれは勘違い
  データを分析し、伝えるのであれば、そのテーマについて一番知っているのはあなたであり、人々を行動に導かなければならない
・必要な情報を把握する
 ・背景、意思決定者が先入観があるか、データをみたことがあるか、賛成しそうかどうか、こちらの主張にリスクがあるか、などなど
・3分ストーリーとビックアイデアを用意する
 ・ビックアイデアとは伝えたいことを1分にまとめたもの。つぎの3つの要素がある
  1.あなたの独自の視点を明確にしている
  2.何が危機にさらされているかを伝えている
  3.完全な文章である

第2章 – 相手に伝わりやすい表現を選ぶ

・データを表現する最善の方法を考える
 ・線グラフか、棒グラフか、表か、テキストが一番良い場合もある
・円グラフ、3Dグラフ、第2縦軸は正確な数値が読みとりにくいため、使うべからず

第3章 – 不必要な要素を取りのぞく

・情報を追加すればするほど、相手に認知的負荷を与える。不要な要素を取り除いていくことで、データがより目立つ
・視覚認知のゲシュタルトの法則を理解して、クラター(認知的負荷の原因)を識別する
・認知的負荷を与える記載をしない
 ・中央揃えは、2行以上ある場合は右側も左側もそろわずだらしない印象を与えるためなるべく避ける
 ・なるべく横書きに統一すること
  45度の方向に回転された文章は、傾きのない文章を比較して 52%読む速度が遅くなる
  90度の方向に回転された文章は、傾きのない文章を比較して205%読む速度が遅くなる
 ・空白を適切に利用すること。息継ぎもなしに早口での話は理解しにくい。文章も同じ

第4章 – 相手の注意をひきつける

・サイズ、色、配置など無意識的視覚情報を戦略的に利用する
・相手の注意を意図するところに集め、意図通りに読んでもらう
・スクリーンやページを読み取る際、人は左からZの形で見ていく
・どこを注目させるか考える際は、一度グラフのすべての色をグレーにしてみるとよい
・色覚障害にも配慮したほうがよい(色覚障害シミュレーターのサイトやアプリがあるため、利用するべし)

第5章 – デザイナーのように考える

・「形式は機能に従う」と同様に、データで何を伝えたいかを考えてから、表現方法を考えるべし
・「足すべきものがなくなった時ではなく、減らすものが何もなくなったとき、それが完璧になったとわかる」(サンテグジュペリ)
・人々が新しいものに抵抗を示すのは、古いものに親しんでいるから
 変化させるときはメリットを明確にする、比較できるようにする、キーマンを巻き込むといった対応が必要

第7章 – ストーリーを伝える

・よい物語は人をひきつけ、旅に連れ出し、感情に直接働きかけ、記憶に残る力を持っている。そしてその物語を友人に話して聞かせる
・理論だけでは人は行動する気にならない。ストーリーをつくることで人々の心に響き、行動につながる
・ストーリーには「始まり、中間、結末」がある。まずは物語の設定から始まる。主人公や登場人物の紹介や関係性や世界観を紹介し
 その後主人公は事件に直面する。この事件を対処しようとする中で自分を理解し、より一段高い気づきに到達する
 そして最後に、事件を解決し主人公やほかの登場人物が、新たな感覚を通じて自分が何者か理解する

Interact 2018 に参加した(2)

Interact 2018に参加した。その際のメモ。

Recap: PowerShell Core – 高井 一輝氏

PowerShell Coreとは何か

Windows PowerShellとの違いについて

・Full .NET Frameworkに依存しないPowerShell
・クロスプラットフォーム
 LinuxやMACでも動作する。
・Windows PowerShellと互換性はあるが、基本的には違うもの
・WMFに(建前上は)依存しない
・SSHが使えるバージョンと使えないバージョンがある
・UTF-8(BOMなし)
・Modern Lifecycle Policy(新しいバージョンが出たら、半年の間にアップデートする必要あり)
・WindowsPowerShellと共存可能
・Windows PowerShellは、今後大幅な機能追加やエンハンスは行われない予定

Powershell Coreへ移行すべきか

No。ただし新しくコードをかく場合はPowerShell Coreを意識してもよいかも。

Powershell Coreを使うべき人

・クロスプラットフォームで利用したい人
・コンテナを利用してWindows管理したい人(開発スピードが早いプロダクトを利用している場合)
・PowerShellの動作を変えたい人(オープンソースのため、どうぞ)

注意点

・LinuxからWindowsへのWinRMの通信は失敗する
 最新のWindowsは認証されていないと受け付けないようになっており、PowerShellCoreでの認証周りの設定が難しい、らしい。

Windows Admin Center -Project Honolulu改め- – 指崎 則夫氏

※Inside Previewを利用しているため、変わってくる可能性も

Windows Admin Centerとは

・ブラウザを利用して、サーバを中央管理することが可能
・EdgeもしくはFirefox(ただし検証はされていない)が無難
・Chromeは画面遷移で認証エラーが多発する
・インストールが簡単(ただし証明書が絡むと少し手間がかかる)
・インストールファイルサイズが数10MBと軽量
・10GB以上のCSVがあれば冗長化構成をとることができる(2ノード以上のWindows Server 2016 failover Cluster)
・イベントログの確認、サービスの起動、ファイルの確認、レジストリの操作など管理できる

Admin Centerからサーバへのアクセス方法

・PowerShell or WinRMで接続するため、各サーバに許可設定をする必要がある

管理される側要件(古いOSについて)

・WinSV2012(WMF5.1以上)
・Win2008R2(WMF5.1以上)も最新のAdminCenterは管理できる
・ワークグループなWindowsはレジストリを登録することが必要

Microsoft Azure Global VNet Peering(仮) – 廣瀬一海氏

・VNet Peeringを利用すると、AzureがSDN(LVGREやSmartNIC(FPGA)を利用)であることを感じられる
・FPGAを利用してパケットチェックして機械学習を利用して、DDoS攻撃を処理している
・Azureは実質WANのようなもの。リージョン間のネットワークもMicrosoftで海底ケーブルを引き、すべて自社網を利用する唯一のパブリッククラウド
・東京リージョンから大阪リージョンへは2msレベル
・Azureは33000マイルの自社網を持ち、世界二位のグローバルネットワークを保有している(1位はペンタゴン)
・ExpressRouteは南極以外からは接続できる
・VNet PeeringはvNETのエンドポイントのBGPルーターを利用して実現している
 制限として10地点としか接続できない
・NW設計について、サブネット分離(Publicサブネット、Privateサブネット)という鉄板も世界をまたいだ設計を考えると、破綻する
 事業ネットワーク、論理ネットワークを考慮して、事業の展開に役立つような設計が大切

Interact 2018 に参加した(1)

Interact 2018に参加した。その際のメモ。

Azureの契約直前・直後に意識しておくこと10箇条 – 足利 惟 氏

Azureそのものの管理の話。

自己紹介

・株式会社pnop所属。
・JAZUG運営メンバー。

Azureの契約プランを一度確認するべし

・サブスクリプションにはさまざまな契約プランがある。
・Visual Studio サブスクリプション(旧MSDNサブスクリプション)には月1万7000円利用できる特典がついている。

従量課金制

・使った分だけお支払い。基本はクレジットカードを利用し、Microsoftへ直接支払い。
・デメリット
 ・会社のクレジットカードを作成する必要がある。(意外と敷居が高い)
 ・請求書払いの場合、SendGridなどサードパーティと外部サービスは購入も支払いもできない。

Azure CSP(Cloud Solution Provider)

・Microsoftがオススメしている。
・サブスクリプション + パートナーが提供する付加価値。
・購入方法はパートナーの仕様に依存し、パートナー経由で購入する。法人のみ。
・デメリット
 ・ASM(旧型式)のリソースは作成できない。移行の際にボトルネックになる可能性がある。
 ・Azure Marketplaceの従量課金製品のほとんどは購入できない。(BarracudaのFW製品など)
 ・Microsoftのサポートは購入できない。(パートナー提供のみ)

EA(Enterprise Agreement)

・大企業向けの一括購入プラン。基本的に1社1アカウント。
・年間160万円以上(?)利用する場合に利用可能。
・LPA(ライセンスプロバイダー)経由で購入。
・デメリット
 ・年間使用分を事前に購入するため、年間金額を予測して購入しないといけない。
  (余ったものは返ってこない。これはクラウド?)
 ・Azure Marketplaceの購入はできるがほとんどの場合は別請求となる。
  (足利さんはオラクルの製品を利用していて、別請求で100万円ほどかかったことがある。)
 ・StorSimpleを利用したいのであれば現状EA一択。

MSA(MicroSoftAccount)と組織アカウントの違いを理解すべし

・MSA:個人で作成できるアカウントで、Microsoftが管理する。
・組織アカウント:企業が組織レベルで作成するアカウント。Azure ADに情報が格納される。
・MSAにリスクがあるため、Azureのアカウントは、すべて組織アカウントで管理することがオススメ。
・MSAのリスク
 ・セキュリティポリシーが強制できない。
  パスワードポリシー、多要素認証、監査など。
 ・5年ログインしないとアカウントが無効になる。
  Azureサブスクリプションの管理者の場合は、サブスクリプションが無効になる可能性がある。

Azure ADは最初に作っておくべし

・MSAを起点としてサブスクリプションを作成すると、メールアドレスに応じたAzure ADテナントが勝手に作成される。
・CSPはこのリスクはない。
・EAの場合は注意が必要。以下URLから先にAzure ADを用意可能。
 https://account.azure.com/organization/

Azure ADの管理者を理解するべし

・Azure ADの管理者はあくまでAzure AD内部を管理する。
 そのためユーザを作成しても、そのユーザはリソースにアクセスできない。
 (サブスクリプションの入力を求められる。もしくはサブスクリプション内で適切なロールを割り当てる必要がある。)

AzureADとサブスクリプションの関係を理解するべし

・Azure AD テナントに複数サブスクリプションを紐づけることが可能。
・Azure AD テナント間でサブスクリプションを譲渡可能。
・MSAはAzure ADではゲストユーザーとなる。
・ディレクトリを一緒にしておくとVNET Peeringを使うことが可能になる。

むやみに管理者ロールを渡すべからず

・RBAC(Role-Based Access Control)を利用して細かくリソース管理すること。
・管理者ロールはサブスクリプションを削除もできるし、所有者を無尽蔵に増やしていくことも可能。
・作業時のリスクを減らすために、適切な役割を割り振るべし。

リソース管理の便利機能を抑える

・リソースロック
 すべてのユーザに削除禁止、読み取り専用どちらかの状態にリソースをロックする機能。
・Azure Resource Policy
 リソースに関する規則を決める。RBACと違いデプロイ中のリソースプロパティに焦点。
 Dシリーズしか作成できない、東京リージョンにしか作成できないなどの制限を付与できる。
・Management Group(Preview)
 複数のサブスクリプションを管理するためのグループ。

サポートは必ず契約するべし

・Standardが値下げされてきている
・テクニカルサポートは有償サポート契約が必要
・パートナーになっている場合は、プログラム特典のサポートが利用できるかも
 (Microsoft Partner Network・MSDN・Signature Cloud Support)

感想、というよりも疑問

・AzureはAzure ADを1つ作成して、そこにユーザを作り、AD周りの権限を与える。
 サブスクリプションをAzure ADに複数割り当てて、ユーザにサブスクリプションごとにリソース権限を与える。
 という使い方であっているのかどうか?
・アカウント管理者(サブスクリプション管理者)とサービス管理者はわけたほうがよいのか?

参考 – わからなくて調べたこと

Azure サブスクリプションから CSP への移行【10/16更新】
Azure の購入方法

Team Geek ―Googleのギークたちはいかにしてチームを作るのか を読んだ

Team Geek ―Googleのギークたちはいかにしてチームを作るのかを読んだときのメモ。

0章 – まえがき

・エンジニアリングの重要な要素であるが、忘れがちな存在の「人間」に焦点を当てている。
・技術集団を率いる人間は、技術への深い愛と造詣が必要。

1章 – 天才プログラマの神話

・リーナスもビル・ゲイツもチームとうまくやる才能があった。
・人は作業途中のコードは見せたがらず、完璧にしてから見せようとする。
 しかし、作業を隠すことで失敗のリスクが高くなる。すでに誰かが対応していたり、簡単なミスに気が付かなかったり、不要なものを作成している可能性がある。
 何度もコンパイルしながらプログラムするように、フィードバックされながら作業したほうがよい。
・チームで働くときのポイントはHRT。謙虚(Humility)・尊敬(Respect)・信頼(Trust)。尊敬は思いやり、その人を高く評価すること。信頼は正しいと信じ、仕事を任せること。
・世の中の関心は常に動く。専門家として新しいことを学ばないと置いていかれる。謙虚に常に学んでいかなければならない。
・弱さ(わからないこと)を見せることは信用を失うことではない。謙虚を見せて、他人の意見を信頼することで、その正直さと強さによって周りが尊敬してくれるようになる。

2章 – 素晴らしいチーム文化を作る

・文化はリーダーではなくチームメンバが作る。そのため強烈な個性をもった新人が現れると、彼の文化がチームに根付くことになる。それが健全な文化になることはとても少ない。
・エンジニアはコミュニケーションをできるだけ排除してコードを書こうとするが、コミュニケーションがないと自分が正しいコードを書いているという保証はない。
(チームと違う方向に進んでいるかもしれない)
・ミッションコミットメントは方向性と、制限されたスコープが必須。
・バグ管理ツールは優先度をつける必要がある。そうしないと、どうでもよいバグを修正して、重大なバグは放置される。
・コードコメントには「なに」は記載せず、「なぜ」を記載する。
・ソースコードは完成してからもさまざまな人によって変化を続けるため、作成者の名前を記載するべきではない。

3章 – 船にはキャプテンが必要

・伝統的なマネージャーはどうやって仕事を完了させるかを考える。リーダーは何ができるかを考える。(どうやって仕事を完了させるかはチームが考える)
・部下を子供として扱えば、部下は子供のように振る舞う。エンジニアを大人として扱うべし。
・マネジメントの仕事はチームの幸せと生産性を高めること。
・マネージャーとしていちばん大事なのは、執事や召使のようにチームに奉仕すること。HRTの雰囲気を出す必要がある。
・パフォーマンスが低い人は高い人の時間を奪う。結果としてパフォーマンスが高い人は流出し、どこにも行けない人たちチームに残る。
・パフォーマンスの低い人は早めに対策する必要がある。そのチームで仕事できなくても、違うチームだと役に立つ能力を持っているかもしれない。
 また向き合う場合は、目標と期日を設定して、毎週進捗確認をする必要がある。
・チームをマイクロマネジメントしなくなれば、メンバのほうがリーダーよりも仕事に詳しくなる。つまり、リーダーは合意形成や方向性の決定を支援することになり
 目標の達成方法はメンバが決定すべきこととなっていく。
・リーダーとしてチームを長期に渡って生産的にするには、チームの幸せを計測したほうがよい。
 1対1のミーティングの後に「何か必要なものある?」という質問をすると、そのメンバが生産的で幸せになるために必要なものを簡単に把握できる。

4章 – 有害な人に対処する

・相手にする価値のない人は無視がオススメ。リソースを食われてしまうため、言葉で言いくるめるよりも無視がよい。
・善人と悪人で分類して悪人を追い出すのではなく、問題ある振る舞いを追い出す必要がある。
・有害な振る舞いに対応する前に、短期的にチームの注意や集中を無駄にしても長期的にプロジェクトにメリットがあるか、衝突は有益な方法で解決できるかを考える。
・無能で十分説明されることに悪意を見出すな。よくわからない人を追放するのではなく、破壊的な振る舞いを受け入れず、HRTに対しての期待を明確にすることが仕事。
 (例えば、ある製品に欠陥が見つかった場合、製造した企業が無能であるか愚かであるということを示しているのであって
 消費者を困らせるために企業が悪意を持って欠陥を忍ばせたわけではない、という考え方のこと。)

6章 – ユーザも人間

・成功しているプロダクトは問題を限定して、それをうまく解決したもの。
 トースター(多くの食材を調理でき、ほぼすべての人が利用できる。ただしラジオ機能(余計な機能)はついていない。)のようなプロダクトを目指すこと。
・プロダクトのユーザが増えると、機能が増えることで複雑性が増す。しかしユーザの平均的な技術能力は低下するため、ユーザの不満が増えていく。
 開発者がユーザの声を聞けるような環境を用意しておくこと。またユーザはシンジられないかもしれないが、開発チームと関係を築きたいと考えている。

[AWS Black Belt Online Seminar] AWS Cloud9 入門 の閲覧メモ

[AWS Black Belt Online Seminar] AWS Cloud9 入門を閲覧した。その時のメモ。

内容


特徴

・セットアップが手間、チーム開発の上でより容易なコラボレーションが必要、既存IDEはサーバレスに追いついていないといった課題解決のためのソリューション
・AWSサービスに直接アクセスできるため、シームレスな開発が可能。
・日本リージョンにはまだ来ていない。
・コスト節約のために、デフォルトでは30分利用しないとインスタンスを停止する。

利用パターンによって、3種類のセットアップ方法がある

・Team Setupでは、開発者チームや開発者チームなどのグループ分けが可能。(IAMグループを利用する)
・AdvanceTeamSetupでは、特別なポリシーを設定するで、TeamSetupより細かく権限制御することが可能。

一部拡張子についてはプレビューを利用可能


言語サポート状況について

・コード補完について ▲:実験的(ベータ版) △:localfunctionのみ ×●:パスを指定すれば利用可能

参考-リリースに関するAWSサービス図-