Деньги без дураков. Почему инвестировать сложнее, чем кажется, и как это делать правильно, Александр Силаев

Apr 25, 2020 Comments

Post Tag: book non-fiction economy

Подробное, логичное и подкрепленное фактами рассуждение о природе фондовых рынков. Необычно и интересно.

Заметки:

К лету 1917 года фондовый рынок России очень сильно подешевел. Все бывалые инвесторы знают, что делать в таких случаях — покупать. Как говорится, покупай на страхе, продавай на эйфории. Обычно при таком поведении зарабатывают, но иногда это делают летом 1917 года в России.
Если нужны данные посвежее, вот ЛЧИ-2017. Конкурс «Лучший частный инвестор» Московская биржа проводит каждую осень. На этот раз требования к участникам ужесточили. К конкурсу допускаются лишь игроки, открывшие первый брокерский счет до 1 января 2017 года, то есть хотя бы с минимальным стажем и с капиталом не меньше 250 000 рублей (до этого было 50 000 и стаж не важен)… Общее количество участников, показавших отрицательный результат, составило 63,74 %, а положительный всего 36,28 %. И это притом что 315 (8,75 %) участников не участвовали или показали доходность менее 1 %. Поэтому реально тех, кто в плюсе, всего 27,53 %. Или почти четверть участников…
На эффективном рынке нельзя в долгосроке получить большую доходность, просто подбирая премию за риск: рано или поздно ее придется отдавать обратно. Если бы это было не так, олигархи не несли бы свои сбережения в швейцарские банки под –0,25 %. Они бы учредили инвестиционные пулы и смели с полок все вкусности по 20–30 % доходности.
Если есть желание пассивно держать индекс, вот простые советы.
1. Никогда не обращайтесь за этим к посреднику. Здесь нет ничего сложного. Справятся и пенсионер, и старшеклассник. Помните о том, что с вас будут снимать от 1 до 5 % годовой доходности ни за что, и стороной обходите фонды.
2. Сами открывайте счет у крупного брокера. Покупайте акции индекса и забывайте. Точность в репликации индекса — ложный фетиш, не вздумайте платить за него те самые 1–5 %. Можете просто купить десять самых увесистых акций в равной пропорции. Но лучше двадцать. Еще лучше пятьдесят. Смотря сколько у вас денег. Индекс, взвешенный по капитализации фри-флоата — доли акций в свободном обращении (именно его продают фонды), — в долгосроке не выиграет у индекса, где всего будет поровну. Скорее, даже проиграет.
3. При открытии и ведении счета используйте все налоговые льготы, какие есть. В настоящий момент в РФ это правило 3-летнего удержания акций, освобождающее от налога, и 3-летнего же удержания ИИС (индивидуально-инвестиционного счета), освобождающего от налога аж двумя способами, на выбор.
4. По итогам года можете чуть-чуть продать или докупить, поддерживая изначальные пропорции. Главное — на протяжении года пореже туда заглядывать.
5. Если играете ассет алокейшн, рулите портфелем акций как частью общего портфеля. Сильно упало — докупили, сильно выросло — перевели средства в другие активы. Колебания в пределах 20 % можно игнорировать, это шум.
Если вы правильно смешаете простые способы играть на ничью, вы получите то, что учебники называют ассет алокейшн, или правильные портфельные инвестиции. Вот их суть вкратце:
1. Поддерживаем постоянные доли простых, надежных, желательно не коррелированных активов.
2. Минимизируем издержки.
3. Что выросло — продаем, что упало — покупаем.
4. И, главное, меньше думаем. Думать здесь вредно.
Как часто продаем и покупаем? Примерно раз в год. Если ничего особо не упало и не выросло, можно ничего не трогать. Но если акции, например, упали или выросли на 50 %, с ними обязательно нужно сделать действие, направленное против движения. Если упали — докупаем (невзирая на страх), если выросли — продаем (невзирая на жадность). Насколько много докупаем или продаем? Настолько, чтобы восстановить изначальные пропорции портфеля. Например, такие: 40 % — акции своей страны, 30 % — долг в национальной валюте, 30 % — долг в долларах США.
Для начала — общая безопасность. Все-таки в редком случае мошенничество возможно. Поэтому — крупный брокер, из первой десятки. Либо брокер при крупном банке (на ум приходят Сбербанк и ВТБ), либо из так называемой первой тройки (Финам, БКС, «Открытие»). Если вы параноик, а правильный инвестор всегда параноик, разложите деньги на 2–3 брокеров.
Подпишите пункт в договоре, запрещающий брокеру пользоваться вашими деньгами и ценными бумагами.
Не все люди могут терпеть просадку капитала, тем более значительную. Инвестирование в акции — это всегда просадка, и часто значительная.
Сколько акций должно быть в портфеле? Вряд ли есть магическое число, скорее можно говорить о нижней границе и верхней. Нижняя граница зависит от представлений о риске. Теоретики спорят о корреляции. Одни полагают, что минимально достаточно 7 акций, другие считают, что даже 15 мало. Я же полагаю, что корреляция — вообще не самая считаемая вещь. Можно посчитать, как это было за десять лет, и обнаружить, что в одиннадцатом году все сломалось.
Итак, любая акция может стать тыквой на 50 %. Тогда, если у вас в портфеле 5 акций, вы теряете без всякого кризиса, на ровном месте 10 % портфеля. Если акций 10, теряете только 5 %. Если акций 20, теряете 2,5 %, и вот здесь уже цифры, с которыми можно жить.
Про это написано много дельных книг, начиная с Бенджамина Грэма и заканчивая Асватом Дамодараном. Поэтому ограничимся конспектом и критикой. Критика означает, что есть нюансы. Главное правило сформулировано давно: покупай по низкой цене хорошие бумаги.
Есть три главных способа поиска недооцененных компаний:
1. Балансовый метод
2. Метод дисконтирования денежного потока
3. Сравнительный метод
Лучше бы, конечно, по будущим дивам — но их никто не знает и нам достаточно, что будущее часто похоже на прошлое. Условия при этом меняются: лучшие дивиденды за прошлый год, три года, десять лет и т. д. И вот здесь все получается. На разных периодах усреднения успехи разные, но везде лучше индекса. В среднем это 5–6 % годовых
В России дивидендные акции предпочтительнее, чем недивидендные. Иными словами, если вы отбирали акции только по величине их прошлых дивидендов, вы уже обыграли российский индекс полной доходности.
Конечно, при желании потерять у вас это получится всегда, на любом рынке, в любом масштабе. Но в целом рынки стали умнее. На них стало больше знания. Например, из практики США: не имеющие никакого знания усвоили единственное, что могли, — знание о своем незнании. Это повысило их шансы, они массово ушли в индексные пассивные фонды. Выбрав игру на ничью, они снизили размер призового фонда. Можешь играть в вэлью-стиле, можешь в тренд-стиле — у них ты уже не заберешь ничего.
Любая деятельность, не требующая личных вложений и не несущая рисков, но с призовым фондом — полезная. Новые знакомства, рассылка резюме, заведение аккаунта в соцсети, хождения по инвесторам с бизнес-планом. Любой безрисковый кипеж — это хорошо. Безриск означает, что в худшем случае вы остаетесь с тем же, что имели. Это как набить карманы бесплатными лотерейными билетами. Дело не в том, что большинство из них выиграет или проиграет, а в том, что вы за них не платили.
Баланс ломается там, где начинают платить за знание. В самом широком смысле слова «знание», как в «Структуре реальности» Дэвида Дойча. Это прекрасная книга, где нет ни слова про экономику, зато есть про квантовую физику, эпистемологию Поппера, неодарвинизм Докинза, машину Тьюринга и как все это связано воедино. Мне эта книга близка, помимо прочего, концепцией знания как фактора эволюции.
Компенсация боли по определению исключает извлечение своей выгоды на обеих сторонах сделки. Компенсация риска — та же самая компенсации боли, только вероятной и будущей. Но инвестор, писатель, музыкант и тысяча их собратьев по нетрудовому доходу могут позволить себе развлечение за вознаграждение.
Правило: не работать только за деньги. Если зарплата единственное, что мотивирует к работе, то это не та работа.
Важно упрямствовать, пытаясь продать свое хобби. Возможно, это будет мотивацией, чтобы стать в нем лучшим. Возможно, найдется другое хобби. Возможно, ничего не получится. Но пока вас радует сам процесс, вы продолжаете оставаться в плюсе.

Сверхдержавы искусственного интеллекта, Кай-фу Ли

Apr 20, 2020 Comments

Post Tag: book non-fiction

Сверхдержавы искусственного интеллекта (Кай-фу Ли)

Заметки:

Хотя первые зерна связанных с ИИ идей проросли на Западе, Китай будет пожинать их плоды. И причина этого глобального сдвига заключается в двух переходах: от эпохи открытий к эпохе внедрения и от эпохи экспертных знаний к эпохе данных.
Итак, человечество приближается ко второму важному переходу – от эпохи экспертных знаний к эпохе данных.
Это, по моему мнению, и будет основной реальной угрозой от искусственного интеллекта – грандиозные социальные потрясения и крах политических систем из-за массовой безработицы и растущего неравенства.
Точное копирование совершенных вещей рассматривается как путь к истинному мастерству. На эту освященную обычаем склонность к подражанию накладывается глубоко укоренившийся менталитет дефицита, который сложился у китайцев в XX веке. Большинство китайских предпринимателей находятся всего в одном поколении от вековой нищеты
Компания iFlyTek активно внедряет ИИ в судопроизводство: она разработала инструменты и реализует пилотную программу в Шанхае, где данные по прошлым делам используются для консультирования судей – как при работе с уликами, так и при вынесении приговоров. С помощью инструментов распознавания речи и обработки естественного языка система сравнивает все представленные доказательства – показания свидетелей, документы, справочные материалы – и находит противоречивые факты.
После десятилетий, в течение которых производительность, заработные платы и количество рабочих мест росли, в какой-то момент связи между ними начали рваться, словно перетершиеся нити. В то время как производительность труда продолжала расти, заработная плата и количество рабочих мест оставались на одном уровне или уменьшались. Это привело к усилению расслоения общества в таких развитых странах, как Соединенные Штаты, где основная прибыль от применения ИКТ оказалась сосредоточена в руках избранных, составляющих 1 % всего населения. В США доля национального дохода, приходящаяся на эту элиту, выросла примерно вдвое в период с 1980 по 2016 год. К 2017 году 1 % американцев принадлежало почти в два раза больше средств, чем 90 % людей из более низких социальных слоев, вместе взятым. В то время как последняя из ТШП распространилась по всей экономике, реальная заработная плата средних американцев осталась на том же уровне, что и 30 лет назад, а заработки самых бедных из них даже упали
Подобно технологиям и промышленности, ИИ естественным образом тяготеет к монополии. Он совершенствуется, получая новые данные, и это создает замкнутый цикл: чем лучше продукт, тем больше пользователей, чем больше пользователей, тем больше данных, а чем больше данных, тем лучше продукт.
Человек и машина, объединившись, могли бы ставить предельно точные диагнозы и одновременно поддерживать и ободрять пациента, чего нередко не хватает в наших больницах. При подобном симбиозе человека и машины мы могли бы сделать наше общество немного добрее.

The Unicorn Project, Gene Kim

Apr 10, 2020 Comments

Post Tag: book management

Двойственное впечатление. Формально все хорошо - бизнес роман об инженере что перешла на “провальный” проект, но не растерялась и привнесла новые технологии, подходы и вместе с командой единомышленников они вместе пришли к успеху. Но есть стойкое чувство как отрабатывается текущая повестка. Гендерное равенство - есть, польза open source - тоже есть, функциональное программирование - присутствует, вовлечённость инженеров в бизнес, work-life баланс и т.д. - добавлено. Все собрали, смешали, запекли, а первая книга, The Phoenix Project, помнится повеселее была. В итоге вышло похоже конечно, но прежней радости от прочтения нет.

Заметки:

“There are Five Ideals,” Erik begins. The whole table turns their attention to him. “I’ve already told you about the First Ideal of Locality and Simplicity. We need to design things so that we have locality in our systems and the organizations that build them. And we need simplicity in everything we do. The last place we want complexity is internally, whether it’s in our code, in our organization, or in our processes. The external world is complex enough, so it would be intolerable if we allow it in things we can actually control! We must make it easy to do our work.”
“The Second Ideal is Focus, Flow, and Joy. It’s all about how our daily work feels. Is our work marked by boredom and waiting for other people to get things done on our behalf? Do we blindly work on small pieces of the whole, only seeing the outcomes of our work during a deployment when everything blows up, leading to firefighting, punishment, and burnout? Or do we work in small batches, ideally single-piece flow, getting fast and continual feedback on our work? These are the conditions that allow for focus and flow, challenge, learning, discovery, mastering our domain, and even joy.”
“In its briefest form: The Third Ideal is Improvement of Daily Work. Reflect upon what the Toyota Andon cord teaches us about how we must elevate improvement of daily work over daily work itself. The Fourth Ideal is Psychological Safety, where we make it safe to talk about problems, because solving problems requires prevention, which requires honesty, and honesty requires the absence of fear. In manufacturing, psychological safety is just as important as physical safety. And finally, the Fifth Ideal is Customer Focus, where we ruthlessly question whether something actually matters to our customers, as in, are they willing to pay us for it or is it only of value to our functional silo?”
Ideals
1. The First Ideal — Locality and Simplicity
2. The Second Ideal — Focus, Flow, and Joy
3. The Third Ideal — Improvement of Daily Work
4. The Fourth Ideal — Psychological Safety
5. The Fifth Ideal — Customer
She’s always been a prolific notetaker. She remembers reading somewhere, “In order to speak clearly, you need to be able to think clearly. And to think clearly, you usually need to be able to write it clearly.”
“We are at the dawn of the Age of Software and Data. Steve and Maggie are even thinking about what data is most important to the long-term success of the company, exploring ways of buying data from our customers and even potentially acquiring strategic data sources. And Steve already knows that technologists are some of the most important people in the company. Which is why you’re a distinguished engineer”

Хулиномика. Хулиганская экономика. Финансовые рынки для тех, кто их в гробу видал, Алексей Марков

Mar 10, 2020 Comments

Post Tag: book non-fiction economy

Смешное, местами правда специфическое, объяснение базовых экономических законов. Ну и ипотечного кризиса США.

Заметки:

Фьючерсные контракты, например, были изобретены в Японии в начале 17-го века в Осаке — их придумали для рынка риса — четыреста лет назад! Они были исключительно японской технологией до 19-го века, а потом их скопировали по всему миру, и сейчас фьючерсный рынок — он циклопического масштаба.
У обычного брокера на бирже в первый год 90 % людей теряют деньги, 5 % в нуле и 5 % зарабатывают. И если вы думаете, что на второй год ситуация улучшается, я вам просто мило улыбнусь.
Поэтому прогрессивное налогообложение — вещь на самом деле правильная и нужная, но вот презентовать и показать её концептуальную полезность никто (из политиков) не отваживается. Или никто не догоняет, все ж тупые как пробка.
Франко Модильяни, нобелевский лауреат 1985 года и автор ряда учебников, искренне считал, что кредит на медовый месяц — одно из лучших вложений человека. Женишься, едешь отжигать. Зачем люди это делают? Для радости и счастья? Может, и нет.
Главный шаг для развития финансовых рынков — это раскрытие информации. Надо заставить организации раскрывать правду одинаково для всех. Вот цитата основоположника этой идеи, американского судьи Луи Брандейса: «Солнечный свет — лучшая дезинфекция». Брандейс был богат, но жил скромно — вместо яхты плавал по речке на каноэ рядом со своей дачей. Он двигал идею, что раскрытие информации должно быть удобным и очевидным.
Такие истории, естественно, оглашаются максимально — и именно поэтому американские рынки работают относительно неплохо. А у нас, например, акции Росбанка выросли на 20 % за день до того, как французский Societe Generale объявил о его покупке. И ничего, все хорошо. Поздравляем победителей нашей беспроигрышной лотереи.
Ещё один чел, управляющий активами по имени Эндрю Рэдлиф, тоже провёл независимое расследование, и выяснил, что чуть ли не все компании выпускают опционы задним числом. Ну не пиздец ли? И он придумал такую тему, что он дико шортил акции этих компаний, а потом объявлял о своём расследовании. Регуляторы мощно наказывали лживые конторы и их топов, а Эндрю подсчитывал свои честные барыши.
Первый большой нефтяной кризис произошёл через сто лет — в 1973–1974 годах, после него и возник рынок нефтяных фьючерсов. В то время на Израиль напали коварные египтяне и сирийцы (кстати, не без помощи СССР), евреи отбились, но куча африканских стран ввела против Израиля эмбарго. Арабы обиделись и в 1985 году начали лить нефть как проклятые — к тому же у них уже была финансовая подушка безопасности. В результате нефть упала с 30 долларов до 12. Между делом сколлапсился и Советский Союз. Многие считают, что действия арабов были спровоцированы рокфеллеровской мафией во главе с ЦРУ, и я готов в это поверить — хотя бы отчасти.
Хедж-фонды забирают жирнейший процент от доходов инвесторов — 1.5–2 % от капитала и 20–25 % от прибыли. Что остаётся инвестору? Разница между теми результатами, которые инвестор получит только за пассивное распределение активов по классам, и теми, что он реально получает, постоянно растёт. ВСЁ БОЛЬШЕ ДОХОДОВ ОТТЯГИВАЮТ УПРАВЛЯЮЩИЕ КОМПАНИИ И МЕНЕДЖЕРЫ ПО ИНВЕСТИЦИЯМ, И ВСЁ МЕНЬШЕ ДОСТАЁТСЯ ТЕМ, КТО ИХ НАНИМАЕТ. Возможно, тут дело в том, что денег в мире становится больше, и малейшая дополнительная доходность становится ценнее. Но эта тема для отдельной книги.
Решение тут простое: избегать тайминга вообще. Движущая сила выбора времени входа в рынок — это эмоция. Страх, жадность, попытка обыграть индекс или соседа, итог — покупаем после роста, расстраиваемся, продаём после снижения, опять расстраиваемся. Это действия вопреки рациональности: ведь куда лучше купить что-то по привлекательной цене и продать против ветра, когда оно дико растёт.

Building Secure and Reliable Systems, Heather Adkins

Feb 20, 2020 Comments

Post Tag: book theory it

Крутая книга, как и прошлые две. Как и раньше, используемые практики, в основном, применимы для достаточно больших компаний. В общем, отличный пример “как надо”. Читаешь и грустишь.

Заметки:

quote an SRE maxim — hope is not a strategy.
The shared infrastructure is a natural place to provide shared defenses. Edge routers can throttle high-bandwidth attacks, protecting the backbone network. Network load balancers can throttle packet-flooding attacks to protect the application load balancers. Application load balancers can throttle application-specific attacks before the traffic reaches service frontends. Layering defenses tends to be cost-effective, since you only need to capacity-plan inner layers for styles of DoS attacks that can breach the defenses of outer layers.
Providing a highly secure, reliable, and consistent software supply chain will likely require you to make many changes — from scripting your build steps, to implementing build provenance, to implementing configuration-as-code. Coordinating all of those changes may be difficult. Bugs or missing functionality in these controls can also pose a significant risk to engineering productivity. In the worst-case scenario, an error in these controls can potentially cause an outage for your service. You may be more successful if you focus on securing one particular aspect of the supply chain at a time.
Consider the very rare issue of memory corruption by bit flip. A modern error-correcting memory module has a less than 1% chance per year of encountering an uncorrectable bit flip that can crash a system. An engineer debugging an unexpected crash probably won’t think, “I bet this was caused by an extremely unlikely electrical malfunction in the memory chips!” However, at very large scale, these rarities become certainties. A hypothetical cloud service utilizing 25,000 machines might use memory across 400,000 RAM chips. Given the odds of a 0.1% yearly risk of uncorrectable errors per chip, the scale of the service could lead to 400 occurrences annually. People running the cloud service will likely observe a memory failure every day.
One system we worked on, used for phone support, allowed administrators to impersonate a user and to view the UI from their perspective. As a debugger, this system was wonderful; you could clearly and quickly reproduce a user’s problem. However, this type of system provides possibilities for abuse. Debugging endpoints — from impersonation to raw database access — need to be secured.
For many incidents, debugging unusual system behavior need not require access to user data. For example, when diagnosing TCP traffic problems, the speed and quality of bytes on the wire is often enough to diagnose issues. Encrypting data in transit can protect it from any possible attempt by third parties to observe it. This has the fortunate side effect of allowing more engineers access to packet dumps when needed. However, one possible mistake is to treat metadata as nonsensitive. A malicious actor can still learn a lot about a user from metadata by tracking correlated access patterns — for instance, by noting the same user accessing a divorce lawyer and a dating site in the same session. You should carefully assess the risks from treating metadata as nonsensitive.
Many excellent books cover the topic of communications thoroughly. For a deeper understanding of communications, we recommend Nick Morgan’s Can You Hear Me? (Harvard Business Review Press, 2018) and Alan Alda’s If I Understood You, Would I Have This Look on My Face?

Kubernetes Up and Running - Brendan Burns, Joe Beda, Kelsey Hightower

Feb 10, 2020 Comments

Post Tag: book it

Самое базовое введение в k8s. Любителям деталей надо искать что-то другое.

Заметки:

Kubernetes_ Up and Running - Brendan Burns, Joe Beda & Kelsey Hightower

This is a good way to verify that your cluster is generally healthy: $ kubectl get componentstatuses
It’s worth noting here that Kubernetes tracks both the requests and upper limits for resources for each Pod that runs on a machine. The difference between requests and limits is described in detail in Chapter 5, but in a nutshell, resources requested by a Pod are guaranteed to be present on the node, while a Pod’s limit is the maximum amount of a given resource that a Pod can consume. A Pod’s limit can be higher than its request, in which case the extra resources are supplied on a best-effort basis. They are not guaranteed to be present on the node.
The Kubernetes proxy is responsible for routing network traffic to load-balanced services in the Kubernetes cluster. To do its job, the proxy must be present on every node in the cluster. Kubernetes has an API object named DaemonSet, which you will learn about later in the book, that is used in many clusters to accomplish this
Kubernetes also runs a DNS server, which provides naming and discovery for the services that are defined in the cluster. This DNS server also runs as a replicated ser‐ vice on the cluster.
Kubernetes uses namespaces to organize objects in the cluster. You can think of each namespace as a folder that holds a set of objects. By default, the kubectl commandline tool interacts with the default namespace
The apply command also records the history of previous configurations in an anno‐ tation within the object. You can manipulate these records with the edit-lastapplied, set-last-applied, and view-last-applied commands. For example: $ kubectl apply -f myobj.yaml view-last-applied will show you the last state that was applied to the object.
All Pods have a termination grace period. By default, this is 30 seconds. When a Pod is transitioned to Terminating it no longer receives new requests. In a serving scenario, the grace period is important for reliability because it allows the Pod to finish any active requests that it may be in the middle of processing before it is terminated
Kubernetes allows users to specify two different resource metrics. Resource requests specify the minimum amount of a resource required to run the application. Resource limits specify the maximum amount of a resource that an application can consume. Both of these resource definitions are described in greater detail in the following sections. Resource Requests: Minimum Required Resources With Kubernetes, a Pod requests the resources required to run its containers. Kuber‐ netes guarantees that these resources are available to the Pod.
When it comes time to change the version of software implementing your service, a Kubernetes deployment supports two different rollout strategies:
- Recreate
- RollingUpdate
The Recreate strategy is the simpler of the two rollout strategies. It simply updates the ReplicaSet it manages to use the new image and terminates all of the Pods associ‐ ated with the deployment. The ReplicaSet notices that it no longer has any replicas, and re-creates all Pods using the new image. Once the Pods are re-created, they are running the new version.
The RollingUpdate strategy is the generally preferable strategy for any user-facing service. While it is slower than Recreate, it is also significantly more sophisticated and robust. Using RollingUpdate, you can roll out a new version of your service while it is still receiving user traffic, without any downtime. As you might infer from the name, the RollingUpdate strategy works by updating a few Pods at a time, moving incrementally until all of the Pods are running the new version of your software.
When the Kubernetes API server starts up, it automatically installs a number of default ClusterRoles that are defined in the code of the API server itself. This means that if you modify any built-in cluster role, those modifications are transient. Whenever the API server is restarted (e.g., for an upgrade) your changes will be overwritten. To prevent this from happening, before you make any other modifications you need to add the rbac.authorization.kubernetes.io/autoupdate annotation with a value of false to the built-in ClusterRole resource. If this annotation is set to false, the API server will not overwrite the modified ClusterRole resource
This kind of indirection may seem overly complicated, but it has a purpose—it serves to isolate our Pod definition from our storage definition. You can declare volumes directly inside a Pod specification, but this locks that Pod specification to a particular volume provider (e.g., a specific public or private cloud). By using volume claims, you can keep your Pod specifications cloud-agnostic; simply create different volumes, specific to the cloud, and use a PersistentVolumeClaim to bind them together. Furthermore, in many cases, the persistent volume controller will actually automatically create a volume for you—there are more details of this process in the following section…

An Elegant Puzzle: Systems of Engineering Management by Will Larson

Dec 16, 2019 Comments

Post Tag: book management

Узнал о книге из канала Qetzal’я. У него же есть отличная выжимка. Книга хорошая, но очень конкретно заточена на личный опыт - как вырасти вместе с компанией в “большого” менеджера. Если у вас амбиции поскромнее, имейте ввиду.

Подборка от него же.

Книги для менеджеров.

Есть два устойчивых мифа о менеджерах. Первый про то, что хороший менеджер это призвание, заложенное в человеке изначально. Если ты такой открытый энергичный человек, душа компании, лидер, cамый заметный — тебе это дано. Иначе — не твое.

Второй миф вытекает из первого. Он про то, что если уж быть менеджером это врожденное, то значит у получаться должно само. Ну просто говоришь всем, что делать и водишь руками.

Это разумеется глупости. Быть менеджером это скилл. Как любому скиллу этому можно научиться. Конечно у кого-то может быть больше начальных способных к этому, у кого-то меньше. Кто-то может любить работать с людьми и решать их проблемы, а кто-то нет (и учиться не хочет). Но прокачаться до нормального менеджера при желании может каждый.

Проблема в том, что этому никто не учит. 12 лет назад был мой первый опыт как руководителя и я его бездарно провалил. Мы успешно запустили новую штуку, но я просто не был руководителем - я был просто хорошим испольнителем (хорошо, что хоть в команде кроме меня был только 1 человек). Второй опыт был немногим лучше, я уже принимал решения и пытался руководить, но как сейчас понимаю совсем не занимался командой. Каждый следующий раз был немного лучше. И сейчас я думаю, что уже что-то понимаю в этом (и очень надеюсь, что лет через 5 буду считать, что сейчас я не понимал ничего)

Лучший способ учится — на примере перед глазами и у ментора. Но не всегда это возможно. В этом случае помогут книги. Есть 6 книжек (и три бонусных), которых я считаю must have для любого менеджера, который работает с людьми. И особенно must have для любого начинающего менеджера. Если вы просто хорошо работали и вас сделали руководителем в первый раз (особенно руководителем тех, с кем вы бок о бок работали) — эти книги вас спасут от кучи шишек. Я бы мечтал прочитать их 12 лет назад!

The Effective Manager (eng) Это четкие конкретные основы про главные инструменты менеджера: 1-1, фидбэк, coaching и делегирование. Это лучшая книга для менеджера. Если можете прочитать только одну книгу — прочитайте эту. Если вы нормально воспринимаете английские подкасты на слух, послушайте основные выпуски их подкаста. Там про то же, что в книге, но подробней. Если зайдет, то и остальные подкасты потом — там есть полезная информация про очень много вещей.
Пять искушений руководителя (ru, eng; в продаже найти сложно, но легко гуглится в электронном виде). Короткий бизнес-роман. Можно прочитать за вечер. О простых и важных концепциях, которые понимают не все: не надо пытаться всем нравится, нужно доверять, не надо боятся конструктивного конфликта и так далее.
Пять пороков команды (ru, eng). Еще один короткий бизнес-роман, читается легко. Продолжает тему предыдущей книги и описывает пять проблем: недоверие, боязнь конфликта, безответственность, нетребовательность и безразличие к результатам.
Трудные диалоги и Язык жизни. Ненасильственное общение. Про то, как общаться и давать фидбэк, если затронуты важные штуки и эмоции.
Принцип «черного ящика». Как относиться к ошибкам, фидбэку и постоянно улучшаться.

Три бонусных книги:

Managing Humans (eng) и An Elegant Puzzle (eng) , моя выжимка на русском. Обе больше про инженерный менеджмент. Managing Humans повеселее и более подходит начинающим менеджерам.
The Score Takes Care of Itself: My Philosophy of Leadership. Очень понравилась, надо ее обдумать и возможно она войдет в общий must have список седьмой.

В догонку, ссылка на список статей про менеджменту с Github. Awesome List of resources on leading people and being a manager.

Hobby project with microservices

Jul 18, 2018 Comments

Post Tag: tech it

This post was inspired by awesome series of tutorials from Ewan Valentine. He built a small microservice oriented web application to select an appropriate ship for every consignment. Technology - Golang, PostgreSQL, MongoDB, gRPC, go-micro framework, React, Kubernetes. I followed through these tutorials. But made some additional “changes”. You can find them below.

General Overview:

Alt text

Consignment Service - “main” service, connected to user(authentication) and vessel(availabe vessels) services. Responsible for creation and displaying consignments. MongoDB is used.
UI Service - simple React app. It is connected to user(authentication) and consignment(consignment managment) services.
User Service - authentication and autorization. It uses PostgreSQL.
Vessel Service - serving creation and finding available vesselss. MongoDB is used.
Infrastructure. Tested locally on minikube.
- db-chart - Helm chart for creating MongoDB and PostgreSQL clusters
- monitoring-chart - Helm chart for creating Prometheus and Grafana
- ingress - Ingress creating for UI and monitoring. Use as:
```
minikube start
minikube addons enable ingress
... helm upgrade ...
echo "$(minikube ip) test" | sudo tee -a /etc/hosts
```

Notes:

Originally the author uses a lot of advantages go-micro framework. It is definitely an interesting topic but a little bit out of my scope. It encapsulates the complexity of gRPC ecosystem but I try to do “by hand” as much work as possible. Also, I have to change Ewan’s source code instead of copying it, that is certainly good for education purpose. One of this framework substitution is implementing grpc-gateway - generates a reverse-proxy server which translates a RESTful JSON API into gRPC. Also, I added a simple swagger output.

httpMux.HandleFunc("/swagger/", func(w http.ResponseWriter, r *http.Request) {
  dir := "./proto/auth"
  if !strings.HasSuffix(r.URL.Path, ".swagger.json") {
    log.Printf("Swagger Not Found: %s", r.URL.Path)
    http.NotFound(w, r)
    return
  }
  log.Printf("Serving Swagger %s", r.URL.Path)
  p := strings.TrimPrefix(r.URL.Path, "/swagger/")
  p = path.Join(dir, p)
  fmt.Println(p)
  http.ServeFile(w, r, p)
})

I got my hands dirty with CORS. Testing UI on the local machine requires specifying two different IP (one for user service and one consignment service). Of course, during CORS it won’t work. The browser doesn’t allow using different addresses. Luckily, grpc-gateway repository has good documentation that helps to fix it.

// allowCORS allows Cross Origin Resoruce Sharing from any origin.
// Don't do this without consideration in production systems.
func allowCORS(h http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        if origin := r.Header.Get("Origin"); origin != "" {
            w.Header().Set("Access-Control-Allow-Origin", origin)
            if r.Method == "OPTIONS" && r.Header.Get("Access-Control-Request-Method") != "" {
                preflightHandler(w, r)
                return
            }
        }
        h.ServeHTTP(w, r)
    })
}

func preflightHandler(w http.ResponseWriter, r *http.Request) {
    headers := []string{"Content-Type", "Accept", "Authorization"}
    w.Header().Set("Access-Control-Allow-Headers", strings.Join(headers, ","))
    methods := []string{"GET", "HEAD", "POST", "PUT", "DELETE"}
    w.Header().Set("Access-Control-Allow-Methods", strings.Join(methods, ","))
    log.Printf("CORS preflight request for %s \n", r.URL.Path)
}

Added a simple health check endpoint for Kubernetes.

httpMux := http.NewServeMux()

httpMux.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
  if err := db.DB().Ping(); err != nil {
    http.Error(w, http.StatusText(http.StatusServiceUnavailable), http.StatusServiceUnavailable)
    return
  }
  w.WriteHeader(http.StatusOK)
})

The general goal of this project is education, so I try to figure out how to work with Consul and implement simple service discovery. Of course, this project runs on Kubernetes and Consul’s service discovery is not necessary. But anyway I implemented registering and retrieving service attributes from Consul.

//Register in Consul
defer func() {
  cErr := consul.Agent().ServiceDeregister(serviceID)
  if cErr != nil {
    log.Println("Can't remove service from Consul ", cErr)
    return
  }
  log.Println("Remove from Consul ", serviceID)
}()

err = consul.Agent().ServiceRegister(&consulapi.AgentServiceRegistration{
  ID:      serviceID,
  Name:    "user-service",
  Port:    50054,
  Address: "host",
  Check: &consulapi.AgentServiceCheck{
    CheckID:  "health_check",
    Name:     "User-Service health status",
    Interval: "10s",
    GRPC:     "host:50054",
  },
})

if err != nil {
  log.Println("Couldn't add service to Consul, ", err)
}
log.Println("Add to Consul, ", serviceID)

//Get IP
ip, err := net.InterfaceAddrs()
if err != nil {
  log.Println("Couldn't get IP address")
}
for _, a := range ip {
  if ipnet, ok := a.(*net.IPNet); ok && !ipnet.IP.IsLoopback() {
    if ipnet.IP.To4() != nil {
      fmt.Println("MY IP: ", ipnet.IP)
    }
  }
}

//Get User-service from Consul
health, _, err := consul.Health().Service("user-service", "", true, nil)
if err != nil {
  log.Println("Cant get live services")
}

fmt.Println("HEALTH: ", len(health))
for _, item := range health {
  log.Println("Service: ", item.Service.ID, item.Service.Address, item.Service.Port)

}

Moreover, I found out that gRPC has in-built support of Consul health checks, but implementation is a little bit weird, the package name has to be grpc_health_v1, otherwise consul could’t use it.

// Check implements Consul health checking
func (srv *service) Check(ctx context.Context, in *pb.HealthCheckRequest) (*pb.HealthCheckResponse, error) {
    if err := srv.repo.ping(); err != nil {
        return &pb.HealthCheckResponse{
            Status: pb.HealthCheckResponse_NOT_SERVING,
        }, err
    }

    return &pb.HealthCheckResponse{Status: pb.HealthCheckResponse_SERVING}, nil
}

Added support of go-grpc-prometheus - allow you to monitor your gRPC methods. It requires adding Prometheus and Grafana to the cluster.
Other changes were pretty small. I changed Docker build to a fancier one, and dep package management, adding Helm support for more convenient deploy to cluster, logging branch name during build etc.
In the end, I couldn’t find out “straight” way of autoincrement consignment id. It could be generated on the consignment service side but might lead to collisions in case of multiple instances, that is highly possible for microservices architecture. Instead of it, after every insert, the id field is updated. It doesn’t look good and if you know a better way I’ll be grateful if you let me know.

func (repo *ConsignmentRepository) Create(consignment *pb.Consignment) error {

    repo.collection().Insert(consignment)
    cons := []test{}
    repo.collection().Find(bson.M{"id": ""}).All(&cons)

    for i, v := range cons {
        fmt.Println(i, v.ID.Hex())
        consignment.Id = v.ID.Hex()
        repo.collection().Update(bson.M{"id": ""}, bson.M{"$set": bson.M{"id": v.ID.Hex()}})
    }

    return nil
}

Пандемия: всемирная история смертельных вирусов, Соня Шах

Oct 28, 2017 Comments

Post Tag: book non-fiction

Один из моих недостатков - сравнивание книг с фильмами. В данном случае фильм-катастрофa как нельзя лучше описывает происходящее в книге. Начитается все с истории возникновения холеры, одного и самых смертоносных заболеваний. Затем описывается как холера поражала целые города в 19 веке, и что за ужасные условия были в этих городах. Следом автор быстренько пробегается по проблемам современного здравоохранения - коррупция, медлительности, сфокусированная на европейских болезнях (лекарства от холеры и малярии слишком дешевы). Рассматривает ближайшее будущее - где благодаря изменению климата, повсеместному использованию антибиотиков, скученности домашних животных, будут появляться новы болезни, опаснее прежних. Ну и в конце кратенько об истории сосуществования людей и вирусов, например, сейчас люди не производят сиаловую кислоту, а раньше производили. И походу все те кто производил, вымерли.

Вот такая веселая книга. Но интересная конечно.

Заметки:

В наше время холера считается болезнью бедных стран, но так было не всегда. В XIX веке холера поражала самые развитые и процветающие города мира, кося бедных и богатых без разбора – от Парижа и Лондона до Нью-Йорка и Нового Орлеана. В 1836 году она лишила жизни Карла X в Италии, в 1849 году – президента Джеймса Полка в Новом Орлеане, в 1893 году – композитора Петра Ильича Чайковского в Санкт-Петербурге. Число заболевших в XIX веке составило сотни миллионов, и больше половины из них скончались.
Первой из новых инфекционных болезней, поразивших зажиточный Запад и разрушивших представление о «постинфекционной» эре, стал вирус иммунодефицита человека (ВИЧ), появившийся в начале 1980-х. Хотя никто не знал, откуда он взялся и как его лечить, многие не сомневались, что медицина с этим выскочкой вот-вот справится. Изобретут лекарства, наладят вакцинацию. … Следом объявились другие инфекционные патогены, такие же неуязвимые для хорошо отработанных, привычных мер профилактики и сдерживания: вирус Западного Нила, атипичная пневмония, лихорадка Эбола и новые разновидности птичьего гриппа, поражающие человека. «Восставшие из небытия» микробы научились противостоять воздействию когда-то эффективных лекарств, и теперь мы имеем лекарственно-устойчивый туберкулез, возрождающуюся малярию и все ту же холеру. Всего с 1940 по 2004 год более 300 инфекционных болезней появились заново или возродились в местах и человеческих популяциях, в которых они не встречались раньше.
Пандемию холероподобного заболевания предрекают многие специалисты. В ходе опроса, проведенного эпидемиологом Ларри Бриллиантом, 90 % его коллег прогнозировали в пределах ближайших двух поколений пандемию, способную поразить до 1 млрд человек, убить до 165 млн и вызвать глобальный экономический спад, убытки от которого достигнут 3 трлн долларов. Пока ни одна из двух пандемий, вызванных новоявленными патогенами – ВИЧ и свиным гриппом, не сравнилась по смертоносности и скорости распространения с холерой. ВИЧ, несомненно, смертельно опасен, но распространяется медленно; свиной грипп в 2009 году распространялся стремительно и широко, но лишил жизни только 0,005 % заболевших.
Хотя микроорганизмы, обладающие потенциалом перехода в человеческие, водятся в самых разных средах, большинство из них, точно так же, как холерный вибрион или вирус атипичной пневмонии, становятся патогенами в организмах других животных. Более 60 % известных патогенов впервые появились у окружающих нас пернатых и хвостатых, в том числе домашних животных – как скота, так и комнатных питомцев. Из них основная масса – свыше 70 % – обязана происхождением диким видам.
Огромная доля человеческих патогенов поступает от других приматов, которые – притом что составляют лишь 0,5 % всех позвоночных – наградили нас 20 % самых тяжких болезней (в том числе ВИЧ и малярией). По той же причине многие человеческие патогены ведут свою историю от зарождения сельского хозяйства примерно 10 000 лет назад, когда люди начали одомашнивать другие виды и вступили с ними в продолжительный тесный контакт. От коров мы получили корь и туберкулез, от свиней – коклюш, от уток – грипп.
У бессмертия, несомненно, есть свои выгоды, но есть и существенные издержки. Одна из них заключается в том, что бессмертный вид очень быстро разрастается до исчерпания необходимых ему ресурсов окружающей среды. И тогда он становится уязвимым для таких бедствий, как голод и пандемии, которые могут уничтожить его одним махом, убив всех представителей разом.
Помимо прочего, в геномах имеются свидетельства о некой пандемии, случившейся далеко в прошлом. Она поразила гоминид (из которых до наших времен дожил только Homo sapiens) около 2 млн лет назад. Указания на нее содержатся в гене, который контролирует выработку вещества под названием сиаловая кислота. На протяжении 300 000 лет – один миг по эволюционным меркам – все производящие эту кислоту особи вымирали или не могли продолжить род, оставляя будущее за теми, кто не вырабатывал сиаловую кислоту, поскольку их вариант гена отключал ее производство. Что могло вызвать такую резкую и быструю перемену? Ученый, обнаруживший утрату этого гена, специалист по сиаловой кислоте Аджит Варки, подозревает пандемию.
Как предполагает специалист по истории болезней Уильям Макнилл, именно такие высоколокализованные особенности иммунного поведения обусловили появление в Индии кастовой системы, строго ограничивающей контакты между кастами и вынуждающей проходить сложные обряды очищения, если контакт все же состоялся. Отчасти, как считает Макнилл, это может объясняться наличием у каждой группы определенного иммунного поведения, направленного против привычных для нее патогенов, и потребностью в системе, стоящей на страже межгрупповых границ.

Операционная система UNIX, Андрей Робачевский

Sep 1, 2017 Comments

Post Tag: book theory

Книга о Unix 1997 года. При это не скажешь что она особенно устарело. Описываются базовые, по-прежнему актуальные, вещи - структура файловой системы, типы процессов, сигналов, подсистема управления процессами, сеть. И все это на русском, очень понятно, с объяснениями и разжёвыванием.

Хороший учебник.

Заметки:

В UNIX существуют 6 типов файлов:
- обычный файл
- каталог
- специальный файл устройства
- именованный канал или FIFO
- символическая связь
- сокет
Обычно программой называют совокупность файлов, будь то набор исходных текстов, объектных файлов или собственно выполняемый файл. Для того чтобы программа могла быть запущена на выполнение, операционная система сначала должна создать окружение или среду выполнения задачи, куда относятся ресурсы памяти, возможность доступа к устройствам ввода/вывода и различным системным ресурсам, включая услуги ядра. Это окружение (среда выполнения задачи) получило название процесса. Мы можем представить процесс как совокупность данных ядра системы, необходимых для описания образа программы в памяти и управления ее выполнением. Мы можем также представить процесс как программу в стадии ее выполнения, поскольку все выполняющиеся программы представлены в UNIX в виде процессов. Процесс состоит из инструкций, выполняемых процессором, данных и информации о выполняемой задаче, такой как размещенная память, открытые файлы и статус процесса.
Процесс в UNIX создается системным вызовом fork(). Процесс, сделавший вызов fork() называется родительским, а вновь созданный процесс — дочерним. Новый процесс является точной копией породившего его процесса. Как это ни удивительно, но новый процесс имеет те же инструкции и данные, что и его родитель. Более того, выполнение родительского и дочернего процесса начнется с одной и той же инструкции, следующей за вызовом fork(). Единственно, чем они различаются — это идентификатором процесса PID. Каждый процесс имеет одного родителя, но может иметь несколько дочерних процессов. Для запуска задачи, т.е. для загрузки новой программы, процесс должен выполнить системный вызов exec(). При этом новый процесс не порождается, а исполняемый код процесса полностью замещается кодом запускаемой программы. Тем не менее окружение новой программы во многом сохраняется, в частности сохраняются значения переменных окружения, назначения стандартных потоков ввода/вывода, вывода сообщений об ошибках, а также приоритет процесса. В UNIX запуск на выполнение новой программы часто связан с порождением нового процесса, таким образом сначала процесс выполняет вызов fork(), порождая дочерний процесс, который затем выполняет exec(), полностью замещаясь новой программой.
Все процессы в UNIX создаются посредством вызова fork(). Запуск на выполнение новых задач осуществляется либо по схеме fork-and-exec, либо с помощью exec(). “Прародителем” всех процессов является процесс init(1М), называемый также распределителем процессов. Если построить граф “родственных отношений” между процессами, то получится дерево, корнем которого является init(1M).
По умолчанию команда kill() посылает сигнал с номером 15 — SIGTERM, действие по умолчанию для которого — завершение выполнения процесса, получившего сигнал. Иногда процесс продолжает существовать и после отправления сигнала SIGTERM. В этом случае можно применить более жесткое средство — послать процессу сигнал SIGKILL с номером (9), — поскольку этот сигнал нельзя ни перехватить, ни игнорировать
Каждый активный процесс в UNIX имеет уникальный идентификатор процесса, PID. Запуская скрипт, вы порождаете в системе процесс с уникальным PID. Значение PID сохраняется в переменной $$. Эту переменную удобно использовать в названиях временных файлов, поскольку их имена будут уникальными
Напомним, что сигналы SIGKILL и SIGSTOP невозможно ни игнорировать, ни перехватить. Сигнал SIGKILL является силовым методом завершения выполнения “непослушного” процесса, а от работоспособности SIGSTOP зависит функционирование системы управления заданиями.
Смысл виртуальной памяти заключается в том, что каждый процесс выполняется в собственном виртуальном адресном пространстве. Виртуальное адресное пространство — настоящий рай для процесса. Во-первых, у процесса создается ощущение исключительности — ведь все адресное пространство принадлежит только ему. Во-вторых, он больше не ограничен объемом физической памяти — виртуальная память может значительно превышать физическую. В результате процессы становятся изолированными друг от друга и не имеют возможности (даже при желании) “хозяйничать” в адресном пространстве соседа. Физическая память распределяется максимально эффективно — она не зависит от распределения виртуальной памяти отдельного процесса.
Можно сказать, что каждый процесс в операционной системе UNIX выполняется на собственной виртуальной вычислительной машине, где все ресурсы принадлежат исключительно данному процессу. Подсистема управления памятью обеспечивает такую иллюзию в отношении физической памяти.
Существуют всего три события, при которых выполнение процесса переходит в режим ядра — аппаратные прерывания, особые ситуации и системные вызовы. Во всех случаях ядро UNIX получает управление и вызывает соответствующую системную процедуру для обработки события. Перед вызовом ядро сохраняет состояние прерванного процесса в системном стеке. После завершения обработки, состояние процесса восстанавливается и процесс возвращается в исходный режим выполнения. Чаще всего это режим задачи, но если, например, прерывание возникло, когда процесс уже находился в режиме ядра, после обработки события он останется в этом режиме.
Для синхронизации процессов, а точнее, для синхронизации доступа нескольких процессов к разделяемым ресурсам, используются семафоры. Являясь одной из форм IPC, семафоры не предназначены для обмена большими объемами данных, как в случае FIFO или очередей сообщений. Вместо этого, они выполняют функцию, полностью соответствующую своему названию — разрешать или запрещать процессу использование того или иного разделяемого ресурса.
Если говорить о производительности IPC, то наиболее быстрым способом передачи данных между неродственными процессами является разделяемая память. Разделяемая память является частью адресного пространства для каждого из взаимодействующих процессов, поэтому чтение и запись в эту область неотличимы, например, от чтения и записи в область собственных данных процесса. Однако при использовании разделяемой памяти необходимо обеспечить синхронизацию процессов.
Индексный дескриптор, или inode, содержит информацию о файле, необходимую для обработки данных, т.е. метаданные файла. Каждый файл ассоциирован с одним inode, хотя может иметь несколько имен в файловой системе, каждое из которых указывает на один и тот же inode.Основные поля дискового inode следующие:
- Тип файла, дополнительные атрибуты выполнения и права доступа.
- Число ссылок на файл, т.е. количество имен, которые имеет файл в файловой системе.
- Идентификаторы владельца-пользователя и владельца- группы.
- Cтарший и младший номера устройства.
- Время последнего доступа к файлу.
- Время последней модификации.
- Время последней модификации inode (кроме модификации полей di_atime, di_mtime).
- Массив адресов дисковых блоков хранения данных.
Поскольку характеристики периферийных устройств значительно различаются, то UNIX использует два основных типа драйверов — символьные и блочные. Как следует из названия, драйверы первого типа обеспечивают обмен сравнительно небольшими объемами данных с устройством, что имеет место при работе, например, с терминалами или принтерами. Драйверы второго типа производят передачу данных блоками, что характерно для дисковых носителей данных. Эти типы драйверов входят в традиционную подсистему ввода/вывода и присутствуют во всех версиях UNIX.
Как уже обсуждалось, старший номер устройства адресует драйвер, в то время как младший номер интерпретируется самим драйвером и может использоваться для различных целей. Например, используя различные младшие номера, процесс может получить доступ к разным разделам жесткого диска, обслуживаемого одним драйвером.