2018-08-26

『転職の思考法』を読んだ

巻末に書いてあるノートまとめを書き写しただけなんですが。とりあえずのメモです。

マーケットバリュー（市場価値）

自分のマーケットバリュー

会社を変えても価値のあるスキルをどれだけ持っているか
そのスキルの賞味期限はいつまでか
他の会社でも通用するレアな経験がどれだけあるか、その経験は世の中からどれだけ強いニーズがあるか
社内に自分が会社を変えても喜んで力を貸してくれる人がどれだけ存在するか、その人物たちは意思決定の力がどれだけあるか
自分が所属しているマーケットに今後の成長性はあるか
今後どれだけ自分の市場価値は成長が見込まれるか

マーケットバリューは何によって決まるか

マーケットバリュー＝技術資産人的資産業界の生産性（1人あたり）
- 給料の期待値は3つの要素の掛け算（イメージ：箱）の大きさ
書き足し：例にあったのだと芸能界は生産性が低い
技術資産は他の会社でも通用する技術的蓄積(2つに分類)
- 職種に紐づく専門性（法人営業）
- 職種に紐づかない経験（マネジメント経験）
人的資産は人脈は自分のために動いてくれる人がどれくらい居るか
業界の生産性は1人あたりの粗利、給料の原資

マーケットバリューの高め方

20代は専門性、30代は経験、40代は人的資産でキャリアを作れ
業界の生産性は市場により最大で20倍違う
マーケットバリューに最大の影響を与えるのは業界の生産性
技術資産と人的資産も少ないなら業界の生産性に振る
- 生産性が高い業界
- 今後伸びる業界

仕事のライフサイクル

仕事はライフサイクルに沿って生まれては消えて言う
ライフサイクルは代替可能性と雇用の数の2軸で考えられる

ーーーーーーーーーーーーーーーーー

①ニッチ
- 始める人、代替可能性は低いが椅子も少ない
②スター
- 儲かることに目をつけ目をつけ同じことをする人が増える状態
- 会社は仕事のプロセスを分解し再現性を確保しようとする
③ルーチンワーク
- 誰でもできるレベルまでプロセスが汎用化されている
- 代替の可能性が高まっている状態
④消滅
- ルーチンワークの代替可能な人を大量に雇っている状態を嫌った会社が技術で人を代替させる
- 椅子の数が激減し、業界全体の利益が減る
伸びている業界に身をおくことはそれだけで価値がある
後追い企業に取って価値ある人材になる
技術資産が高くても衰退する業界にいてはマーケットバリューが減っていく

マーケットを見つける方法

複数のベンチャーが参入し各社が伸びているサービス
既存業界の非効率をつくロジック

転職先となる会社の見極め

3つの基準

マーケットバリューは上がるか
働きやすいか
活躍の可能性は十分か
働きやすさはマーケットバリューと相反しない。むしろ長期的には一致する
活躍の可能性を確かめる質問
- どんな人物を求めていてどんな活躍を期待しているか
- 今一番社内で活躍し評価されている人はどんな人物か、なぜか
- 中途で入った人物で今活躍している人はどんな社内パスを経てどんな業務を担当しているのか

いいベンチャーを見極める

競合はどこか、競合も伸びているか
同業他社からの評判は悪くないか

新卒で入るべき会社と中途で入るべき会社のち外

中途を生かすカルチャーの有無
- 役員が新卒出身者で占められている会社は要注意
自分の職種が会社の強み（エンジン）と一致しているか
どんな人材でも回るビジネスモデルかどうか

転職エージェント

ビジネスモデル

1人の候補者が2つのエージェントからA社を紹介した場合、最初に接点を作ったエージェントが報酬をもらう権利を得る
そのためエージェントは他エージェントとの接触を嫌う
できるだけ早くたくさん企業を紹介し受けさせようとする

良いエージェント

面接時懸念点までもフィードバックしてくれる（自分から聞くこと）
自分のキャリアにとってどういう価値があるのかという視点でのアドバイス
企業に回答期限延長や年収交渉をしてくれる
他に良いのないかという質問に粘り強く付き合ってくれる
社長や役員、人事責任者との面接を自由にセットできる

なぜ企業はエージェントを使うか

企業側の採用方法
- ヘッドハンティング
- エージェント
- ダイレクトリクルーティング
- SNS -　直接応募
エージェントを使うのは離職率が以上に高い、紹介がない
エージェントが強く勧める会社は採用基準が低い（かも
エージェント経由だけで会社を絞ってはいけない
自分で頭にある企業があるなら他のチャンネルも使うべき
- 書き足し：勉強会参加〜のチャンネルもある

転職後の給料

既に給料が高い企業、今は給料低いけど今後マーケットバリューが上がる企業があれば後者
マーケットバリューと給料は長期的に一致する

仕事における楽しみ

being と to do

何をするかに重きを置くto do型
どんな人でありたいか、どんな状態でありたいかに重きを置くbeing型
99%がbeing型（らしい
心からやりたいことがなくても悲観しなくて良い

being型にとって重要なこと

RPGで考えるとわかりやすい
- 自分の状態主人公は適切な強さか、信頼できるか
- 環境の状態
  - 緊張と緩和のバランスは心地よいか

自分の状態を整えるには

マーケットバリューを高める主人公は強くないと戦えない
仕事でつく嘘を最小化する

環境の状態を整えるには

直近半年で強い緊張を感じた場面を書き出す
悪い緊張が10以上
- 職場を変える
良い緊張が3つ未満
- より難しい業務ややたことのないことに挑戦が必要

being型が好きなことを見つける方法

小さなやりたいことで良い
- 他の人からうまいと言われるが自分ではピンと来ていないもの
- 普段の仕事で全くストレスを感じないこと

自分にラベルを貼る

自分の好きなこと、苦にならないことをラベルにする
- 理想でも未達でもOK
このラベルがより強固になるかという判断軸で仕事を選んでいく

転職と不安

失敗とは

失敗かどうかは事後的にしかわからない
失敗する条件は条件は覚悟w決めるべきときに覚悟を決められないこと
転職を阻害するのはほとんどが見栄と恐怖

転職が当たり前の社会へ

転職が当たり前になれば個人はより自由に。社員を惹きつける会社はより魅力的に。

ーーーーーーーーーーーーーーーーーーーー

他印象に残った文

引く手あまたの人材が転職せずに働き続けている会社が良い会社

2018-04-10

td-agent のプロセスが死んでから復旧するまでの間に in_tail で監視しているファイルにログが追記されてローテートされると追記されたログが拾えない

タイトルが長くてすみません。

事象としては掲題の通りです。

以下に確認したことをメモします。

環境

アプリが出力するログをtailプラグインを使ってアグリゲータに送信
アグリゲータはs3にログをputする
送信側のtd-agent バージョンは 1.1.3
送信ログは2GBごとにローテートされる
以下のようにだいたい10分に1回ローテートされます。

[root@送信 ~]# ls -ltrh /var/log/test.log*
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 10:16 /var/log/test.log.20
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 10:25 /var/log/test.log.19
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 10:34 /var/log/test.log.18
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 10:43 /var/log/test.log.17
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 10:52 /var/log/test.log.16
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 11:00 /var/log/test.log.15
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 11:09 /var/log/test.log.14
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 11:17 /var/log/test.log.13
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 11:26 /var/log/test.log.12
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 11:34 /var/log/test.log.11
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 11:42 /var/log/test.log.10
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 11:50 /var/log/test.log.9
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 11:58 /var/log/test.log.8
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 12:06 /var/log/test.log.7
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 12:14 /var/log/test.log.6
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 12:22 /var/log/test.log.5
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 12:29 /var/log/test.log.4
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 12:37 /var/log/test.log.3
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 12:45 /var/log/test.log.2
-rw-rw-r-- 1 ec2-user ec2-user 2.1G Apr 10 12:52 /var/log/test.log.1
-rw-rw-r-- 1 ec2-user ec2-user 115M Apr 10 12:53 /var/log/test.log

設定

具体的な設定は以下のようにしました。

今回は受信側の設定も載せていますがあんまり関係ないですね。

送信側

test.logをtailします

<match tail.test>
  @type forward
  transport tcp

  <buffer tag,time>
    @type file
    path /var/log/td-agent/buffer/
    chunk_limit_size 64m
    queue_limit_length  2560
    timekey 3600 # 1 hour partitioon
    timekey_use_utc true # use utc
    flush_mode interval
    flush_interval 5s
    flush_at_shutdown
    retry_timeout 5m  #default = 72h
    #retry_max_times 5  #default = none
  </buffer>

  <server>
    host xxxxxxxxxxxxx
    port 24224
  </server>
</match>

<source>
  @type tail
  format none
  path /var/log/test.log
  pos_file /var/log/td-agent/test.pos
  tag tail.test
</source>

受信側

今回は確認のために受信した内容をそのままファイルに吐き出します。

<match tail.test>
  @type file
  format single_value
  path /var/log/td-agent/tmp.log
  append true

  <buffer>
    @type file
    path /var/log/td-agent/buffer/
    flush_mode interval
    flush_interval 5s
  </buffer>
</match>

## built-in TCP input
## @see http://docs.fluentd.org/articles/in_forward
<source>
  @type forward
  port 24224
  bind 0.0.0.0
</source>

確認方法と事象

送信側のlogに適当に書き込みます

[root@送信 ~]# for i in `seq -w 01 05` ; do echo "`date`      $i" >> test.log ; done

受信側で確認します

[root@受信 ]# tailf tmp.log
Tue Apr 10 11:54:58 UTC 2018      01
Tue Apr 10 11:54:58 UTC 2018      02
Tue Apr 10 11:54:58 UTC 2018      03
Tue Apr 10 11:54:58 UTC 2018      04
Tue Apr 10 11:54:58 UTC 2018      05

送信側のtd-agentを止めて、先ほどと同じ要領でログを追記してみます

[root@送信 ~]# /etc/init.d/td-agent stop
Stopping td-agent: td-agent                                [  OK  ]

[root@送信 ]# for i in `seq -w 06 10` ; do echo "`date`      $i" >> test.log ; done

[root@送信 ]# cat test.log
Tue Apr 10 11:54:58 UTC 2018      01
Tue Apr 10 11:54:58 UTC 2018      02
Tue Apr 10 11:54:58 UTC 2018      03
Tue Apr 10 11:54:58 UTC 2018      04
Tue Apr 10 11:54:58 UTC 2018      05
Tue Apr 10 13:00:54 UTC 2018      06
Tue Apr 10 13:00:54 UTC 2018      07
Tue Apr 10 13:00:54 UTC 2018      08
Tue Apr 10 13:00:54 UTC 2018      09
Tue Apr 10 13:00:54 UTC 2018      10

手動でtest.logをローテートします

[root@送信 ]# logrotate -f /etc/logrotate.d/test

再度ログを書き込んでみます

[root@送信 ]# for i in `seq -w 11 15` ; do echo "`date`      $i" >> test.log ; done

[root@送信 ]# cat test.log
Tue Apr 10 13:10:59 UTC 2018      11
Tue Apr 10 13:10:59 UTC 2018      12
Tue Apr 10 13:10:59 UTC 2018      13
Tue Apr 10 13:10:59 UTC 2018      14
Tue Apr 10 13:10:59 UTC 2018      15

td-agentを起動して受信側のログを確認します

[root@送信 ]# /etc/init.d/td-agent start
td-agent td-agent:                                         [  OK  ]

[root@受信 ]# tail tmp.log
Tue Apr 10 11:54:58 UTC 2018      01
Tue Apr 10 11:54:58 UTC 2018      02
Tue Apr 10 11:54:58 UTC 2018      03
Tue Apr 10 11:54:58 UTC 2018      04
Tue Apr 10 11:54:58 UTC 2018      05
Tue Apr 10 13:10:59 UTC 2018      11
Tue Apr 10 13:10:59 UTC 2018      12
Tue Apr 10 13:10:59 UTC 2018      13
Tue Apr 10 13:10:59 UTC 2018      14
Tue Apr 10 13:10:59 UTC 2018      15

td-agentが止めてから書き込まれたログは無視されています。

ローテート後のファイルからしかforwardされていません

考察

posファイルにはwatchするログのi-nodeと位置が記録されていますが、プロセスが落ちて起動させた際、これまでのposファイルに記録されたファイルや位置に関係なく、設定されたtail対象のファイルを探してi-nodeが更新されてしまうようです。

僕はposファイルのi-nodeが更新される前に、posファイルに記録されているi-nodeのファイルを最後まで読み切ってから次のファイルを見つけてtailすると思っていたのですが、そのような挙動では無いんですね、、

回避方法

約10分に1回ローテートが走る今回の環境ではtd-agentのプロセスが突然死する障害が起きた場合、例えば30分程度検知〜復旧に時間がかかると欠損が出てしまいます。

いろいろ調べましたが今回の事象を回避するようなオプションを見つけることが出来ませんでした。

このような場合にはいかにtd-agentのプロセスが死んでからの復旧を早めるかが重要になりそうです。

今回はmonitやsupervisorなどを使ってなるべくプロセスが死亡し続けないようにして回避できればなと考えています。

最後に

こんなのこういう風にすれば回避できるよとかあれば情報を頂けると助かりますm( )m