#Серьезный #CTO-шный вопрос - а есть тут люди которые на AWS делают Security Policy as code ? Тут в местном телеком-консалтанси год назад делал чел презентацию про Azure  и вручную изготовленные скрипты (довольно элегантное решение). Интересно, если есть кто решает эту проблему на AWS -
1. Что есть готового или "для доработки напильником" на чистый AWS (не в кубер)?
2. Какие проблемы были\есть ? Как решили их (если не NDA) ?
3. Если бы сейчас предложили бы сделать то же самое - сделали бы по-другому или вообще бы не ввязывались ? Почему ?
4. Что вообще можете рассказать об организации\проекте с таким подходом - плюсы\минусы....

я общался с одним госом, у которого свой цод охраняет своя вооруженная армия. Я не знаю что должно произойти, чтобы они куда-то переехали. Мне кажется наше поколение не понимает фобий тех, кто сейчас у руля.

вопрос денег, если у них есть бабки на свою армию, на одменов в цод и вмвер там тоже значит есть

Для себя я нашел две шикарные книги (правда вторая - больше повторение первой другими словами):
https://www.amazon.com/Crucial-Conversations-Talking-Stakes-Second/dp/1469266822
https://www.amazon.com/Crucial-Accountability-Resolving-Expectations-Commitments/dp/0071829318

В локальном CTO-Meetup чате  exCTO Envato (James Ross очень клевый чел) делился тем, что он первую книгу  прочитал 4 или 5 раз уже. Я сам уже 3 копии этой книги подарил близким людям, но в плане чтения - только один круг завершил.


Из собственной практики:

- Регулярный 1-on-1, с подготовкой и проработкой,  в формате radical candor - прямой откровенный фидбэк, конструктивный поиск решения проблемы,  все строго конфиденциально, установить доверительные отношения с человеком, дать ему канал для обратной связи наверх. В большинстве случаев люди не говнюки (иначе - это был массивный факап при найме, ) и они просто не умеют говорить про проблемы. Человек сам расскажет про свои морковки, надо уметь слушать.
Как научить этому - хрен знает, есть люди у которых это получается естественно, есть те, кто учится, есть те кому не дано или нужно очень много ментальных усилий.  Для меня эта область в плане обучения выглядит как такое "ремесленичество" - нет научного подхода, но есть приемы которые работают, эти приемы передаются из уст в уста в разных менторских сессиях (типа вот такого сервиса https://www.platohq.com/mentors/ )

- SWOT анализ человека хорошо помогает понять как его видят со стороны и как он видит сам себя - делать это раз в год и разрабатывать план карьерного\экспертного роста.

- Еще есть книжка про 5 языков любви - она из психологии, но идея та же - у разных людей стимулы выражаются в разных вещах - кто-то работает просто за деньги, т.е. его морковки упрощенно - премия\штраф, кто-то хочет чтобы ему уделяли время - поставить его в парное программирование с кем-то, кто-то хочет признания - выделить время на подготовку внутренних докладов или там сайд-проекты какие.

Важно понять - какие скрытые причины у человека так себя вести на работе и потом работать над исправлением этих причин. Науки тут конечно нету, есть "приемчики" ну и как и везде - нужно осознанно инвестировать в эту область время, деньги и внимание. Это не работает, что один раз объяснил\показал фреймворк и все поняли и сами исправились и начали самоулучшаться - это отдельный stream of work со своими навыками, отчетами, накоплением опыта и т.д. Без инвестиции времени - никакой framework не поможет.

Еще бывает что проблема не в человеке а в команде - не принимают его и не идут на контакт. На эту тему у меня еще непрочитанная  Patrick Lencioni "The five disfunctions of a team" (https://www.amazon.com/Five-Dysfunctions-Team-Leadership-Fable/dp/0787960756), но тут снова - надо понять суть конфликта команды и индивида.

вы меня конечно извините - но вот коллективные советы в чатике по вашему вопросу могут сделать ситуацию еще хуже. Тут могут быть миллионы вариантов и в них нужно действовать разными способами, по паре-тройке сообщений в чате ситуацию не вытащить наружу

Поддерживаю твою обеспокоенность и очень надеюсь что автор просьбы достаточно опытен, чтобы не пытаться собирать реактор по советам из интернета.  В общем, всем добра. PS. я просто прочитал только что 170 сообщений и поэтому пульс дискуссии не прочувствовал, скорее просто как книгу почитал :)

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

обожаю истории, как у IBM можно купить самый последний series z и запустить на нем софт для OS/360 as is

вы меня конечно извините - но вот коллективные советы в чатике по вашему вопросу могут сделать ситуацию еще хуже. Тут могут быть миллионы вариантов и в них нужно действовать разными способами, по паре-тройке сообщений в чате ситуацию не вытащить наружу

обожаю истории, как у IBM можно купить самый последний series z и запустить на нем софт для OS/360 as is

Задачи типа ротации ключей, деактивации неактивных пользователей, удаления мусора из S3 и тд выношу в step functions, которые запускаются по расписанию используя cloudwatch event.

Последний шаг во всех step functions вызов healthchecks.io, который выполняет роль  dead man’s switch и контролирует что все процессы были выполнены в срок.

Задачи типа ротации ключей, деактивации неактивных пользователей, удаления мусора из S3 и тд выношу в step functions, которые запускаются по расписанию используя cloudwatch event.

Последний шаг во всех step functions вызов healthchecks.io, который выполняет роль  dead man’s switch и контролирует что все процессы были выполнены в срок.

хм, чет сломалось. Думаю это всё из-за стикеров

Для этого есть cloudtrail logs и trusted advisor, но в нашем случае оказалось гораздо эффективнее раз в месяц проводить cleanup day. Отдельно выделенный день когда мы чистим инфраструктуру, вики, гит, тесты, беклог и тд