$shibayu36->blog;

株式会社はてなでエンジニアをしています。プログラミングや読書のことなどについて書いています。

「0〜3歳の子育てハッピーアドバイス」読んだ

0~3歳の これで安心 子育てハッピーアドバイス

0~3歳の これで安心 子育てハッピーアドバイス

育児に対する意識が落ちてきたので、そろそろ上げておかないとなということで読んだ。良い本だった!

この本は0~3歳までの子育てで親が大事にすべき行動を教えてくれる。昔「子どもへのまなざし」という本を読んだのだけど、基本的な思想はこの本と同じで、3歳までは子供の要求を満たしてあげましょうと書かれている。「子どもへのまなざし」よりもさらに具体的な行動が書かれているので参考になった。

子育てで大事にすべきことわからん!ってなったら、変にちゃんとやれって煽ってくる育児書を読むより、「子どもへのまなざし」や「0〜3歳の子育てハッピーアドバイス」あたりを読むのが良いと思いました。

読書ノート

* 依存(甘え)と自立(反抗)は行ったり来たりする 52
* 甘えさせると甘やかすは違う 74
* 子供の反抗には共感をする 82
* 一度肯定してから、しつけをする 95
* 癇癪を起こす子供には一回共感。その後抱きしめる、ダメな理由を説明する。それでも言うことを聞かなかったとしてもダメなことはダメと伝える 134、138
* ダメと言わずにやめさせる。くすぐり作戦、あれ何作戦、泣き真似作戦 139
* 2歳児で止めなければならないのは、危険なこと、人を傷つけること、生活のリズムが崩れることだけ。それ以外はある程度許容する 139
* 5人に1人はひといちばい敏感な子がいる 148
* 保育園の長さは発達にほぼ影響せず、家族での食事の影響度は高い 241
* イヤイヤには目先を変えたり、2択にしてみたりする 250
* 子育ての悩みの9割は年齢とともに解決する 310

topにおけるCPUのsteal/niceは何か調べた

入門監視を読んだところ、CPUのstealやniceが何か分からなったため調べてみた。今回はそのメモを書いてみる。あまり自信はないので間違っていたら指摘してください。

steal

リソース制御でサービスレベルを確保せよ (2/3):実践! Xenで実現するサーバ統合(5) - @IT が参考になった。

steal列には、ゲストOSがリソース要求を行ったにもかかわらずCPUリソースを割り当ててもらえなかった時間の割合が表示されます。steal列に0%以外の値が表示されている場合はCPU利用率閾値設定が行われているか、ほかのゲストOSあるいはホストOSが同時にCPUリソースを要求して「取り合い」の状態になっていることが考えられます。特に閾値を設定していないにもかかわらずこのstealの値が高いようであれば、そのホストサーバは全体として過負荷になっているか、前述のCPUマッピング設定がアンバランスになっている可能性が高いと判断できます

パフォーマンスが出ない状態でstealが占める割合が高い場合、VM周りで何か問題が起こっていることが考えられる。例えばホストOSが何らかの理由で異常に負荷がかかってしまっているとか。

もしstealが高い場合でAWSを使っているなら、ホストの障害が起こっている可能性があると考えて、インスタンスのstop -> startを試してホストを変えてみると治るかもなーと思った。

nice

niceの調査は結構難しかった。以下の文献が参考になった。

man topで参考になるのは

us, user : time running un-niced user processes
sy, system : time running kernel processes
ni, nice : time running niced user processes
...
13. NI -- Nice Value
The nice value of the task. A negative nice value means higher priority, whereas a positive nice value means lower priority. Zero in this field simply means priority will not be adjusted in determining a task's dispatch-ability.

このあたりを総合すると

  • CPUにおけるnice値はlow priorityなプロセスが占めている率
    • man topではuserはun-nicedと書いていると書いているので、CPUのnice値とは逆と考えたら良さそう
  • CPUのnice値を読み解くときは
    • CPU利用率が高く、かつCPUのnice値が高い場合、low priorityなプロセスが多いだけなので、優先度が高いプロセスが現れたらそっちにCPU使われる。そのため問題ないことが多い
    • CPU利用率が高く、CPUのnice値が低い場合、優先度が高いプロセスが多くCPUに余裕がない状態
  • 優先度の意味でのniceの値(niceコマンドで設定できる)は-20~19の値が取れる。-20が優先が最大で、19が優先度が最低(プラスとマイナスの意味が逆転してる)。

という感じ?ただこの文章を書いてみて次のことも同時に思った。

  • niceコマンドで優先度の意味のniceの値を-20(つまり通常のプロセスより優先度が高い状態)にした場合、そのプロセスはnicedなプロセスになってCPUのnice値も上がるんじゃない?
  • そうすると、次の文章は嘘かも? -> 「CPU利用率が高く、かつCPUのnice値が高い場合、low priorityなプロセスが多いだけなので、優先度が高いプロセスが現れたらそっちにCPU使われる。そのため問題ないことが多い」

この疑問はまた別途考える。

まとめ

今回は「入門 監視」を読んで疑問に思ったstealとniceの値について調べてみた。何か間違いがあったら教えてください。あとniceはやっぱりよく分かってない部分も多いのでそちらも知りたい。

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

「エンジニアメンター制度の効果的な運用を目指して」という発表をEngineering Manager Meetup #5でしました

「エンジニアメンター制度の効果的な運用を目指して」という発表をEngineering Manager Meetup #5でしました
Engineering Manager Meetup #5で「エンジニアメンター制度の効果的な運用を目指して」という発表をしてきました。

自分も久々の発表で緊張しましたが、自分の頭をまとめる良い機会になりました。他の発表も学びが多く、とにかく濃いミートアップでした。このような機会を与えてくれた運営の方に感謝です。また機会があったら参加・発表したいです!

以下は発表内容のまとめです。

発表内容

アジェンダ

  • はてなのチーム横断のエンジニアメンター制度とは
  • 実際にどのような課題があったか
  • どのように改善したか
  • 改善施策により最終的にどうなったか
  • 今回の施策を通しての気付き: マネージャ向けにも当たり前のことをする

イントロ

  • 自分がマネージャっぽい仕事をしていると以下のような課題を感じることがあった
    • 初めてマネージャになったけどまず何をしたらいいかさっぱり
    • 目標設定、1on1、評価などをやっているけど手応えがない
    • そもそもどうやって悩みや問題を解決していったら良いのか分からない
    • マネージャスキルをどう身につけたらよいか分からない
    • (Manager of Manager視点): マネージャスキルをどうやって横展開していけばよいのか分からない
  • はてなのチーム横断エンジニアメンター制度でも同じ課題が存在した
  • その課題をどう解決していったか紹介

チーム横断のエンジニアメンター制度とは

これです -> https://developer.hatenastaff.com/entry/2018/05/30/173000

実際にどのような課題があったか

  • そもそも課題があるのか?の検証から始めた
  • そのためにメンターをやっている人にアンケート
  • アンケートの結果、メンターが手応えを全く感じておらず、やはり課題があるという結論になった
  • 課題が残っていると、効果的にメンター制度が運用できない/メンターを増やせず組織はスケールしないと考え、取り組むべきであると結論づけた
  • アンケートを分析すると、4つの課題に絞り込めた
    • メンターとなった時、最初何をしたらいいかさっぱり
    • どういうスキルを身につければよいか分からない
    • メンター同士のつながりがなく、解決できない問題を相談できない
    • メンティーの役に立っているのかが判断できず、メンターが手応えを感じてない

どのように改善したか

  • 改善策を三つ実施した
    • マニュアル、推薦書籍、そして導入会
    • メンターグループ会
    • フィードバックアンケート
  • なぜこの施策が良いと考えたかや、どのように行ったかの詳細はスライド参照

改善施策により最終的にどうなったか

  • 再度メンターにアンケートを送り、役割ごとの手応えや、施策が実際役立ったかについてアンケートした
  • 役割ごとの手応えは、施策実施前にアンケートを送ったときより総じて向上した。施策の効果が出ていると実感
  • 施策の役立ち度合いとしては、特にメンターグループ会とフィードバックアンケートの評価が高かった
    • その他施策ごとの感想についてはスライドを参照
  • この施策を実施してから一年後、メンター数も8人増員し、大体二倍程度に増やすことが出来た。スケールをすることが可能になった

今回の施策を通しての気付き: マネージャ向けにも当たり前のことをする

  • 今回やった施策はメンバーにとっては当たり前のことばかり
  • 当たり前のことをマネージャ向けには出来ていなかった。なんとなく大丈夫でしょと思っていた
  • しかしまず当たり前のことをするだけでも効果があった
  • 画期的なものの導入だけでなく足元の整備も同時に大事
  • 今後もひとつずつ改善していきたい