#машины_aws
Ребята из MadDevs сделали то, что я хотел как-то попробовать сделать чисто для себя - приватное облако на базе Kubernetes с разбиением по пространствам имен и прочими рюшечками для мультитенантоности.
Это не первый раз, когда меня опережают в идеях (как минимум потому, что в моем случае идея чаще всего остается только идеей), но раз уж на то пошло - стоит на это дело обязательно взглянуть.
Что я и сделал.
Ребята из MadDevs сделали то, что я хотел как-то попробовать сделать чисто для себя - приватное облако на базе Kubernetes с разбиением по пространствам имен и прочими рюшечками для мультитенантоности.
Это не первый раз, когда меня опережают в идеях (как минимум потому, что в моем случае идея чаще всего остается только идеей), но раз уж на то пошло - стоит на это дело обязательно взглянуть.
Что я и сделал.
Anonymous Poll
57%
Давай уже!
43%
Нет, все еще не н-нада!
Forwarded from Уютный IT адочек
Friendly Asked Questions #1 — про уникального эксперта
Я руководитель команды из 10 человек. Когда мой разработчик Алексей уходит в отпуск, куча вопросов "встаёт" до его возвращения, нет никого, кто был бы настолько же в курсе отдельных частей проекта. Разработчику это похоже очень нравится, на моё предложение, чтобы он кого-то научил, передал свои знания реагирует агрессивно. Что делать? Если будут проблемы — всех собак повесят на меня.
Ответы дали авторы каналов Уютный Адочек, Человек и машина и Scrum Master Notes
А мы ждём ваших вопросов в: https://forms.gle/sKyaEuqQMMyFJBxJ8
@scrummasters — Василий Зорин
Все сильно зависит от команды и установившегося статуса кво внутри. Я бы начал с совместной ретроспективы: послушайте, что беспокоит команду, видит ли она эту проблему. Если да - отлично, значит разработчики сами предложат решение, а “Алексею” будет трудно игнорировать мнение коллег. Если команда эту проблему на замечает или обходит стороной - инициируйте разговор самостоятельно, через обсуждение кейсов, которые произошли в результате этой “зависимости” от “Алексея” (задержка релиза из-за отпуска “Алексея”- хороший повод).
Никто лучше самой команды не может сказать, как именно организовать процесс передачи знаний, поэтому главное - это подсветить проблему команде. Если сложившиеся отношения внутри команды не позволяют открыто обсуждать эту проблему, то нужно потратить время на формирование доверия и командной отвественности за результат. Если времени на это нет - прийдется действовать директивно и избегать появления подобных “Алексеев” в будущем.
@manandthemachine — Карен Товмасян
Ох уж эти Всезнающие Алексеи!
Позволю предположить, что Алексей в конторе был задолго до %username%, иначе непонятно, как подчиненный смог выстроить такую политическую игру.
Не стоит просить кого-то заняться обучением других, это должно быть не просьбой, а задачей.
Если же человек не хочет выполнить такое поручение, то стоит задаться вопросом, не боится ли этот человек потерять ценность для команды и проекта/продукта? Я уверен, нормальная встреча 1-1 приоткроет завесу тайны.
Но предположим, что Леха-карьерист таким образом решил кого-то (вас) подсидеть, и поэтому контакт не налаживается. Решение в таком случае жесткое: уволить и принять удар.
Да, с собаками придется повозиться, но я не слышал ни об одном предприятии, которое закрылось из-за ухода ключевого сотрудника.
@lovely_it_hell — Цупко Игорь
Многое зависит от того, сколько у вас времени на решение этой проблемы и какие есть доп. ресурсы. Когда они есть – можно либо вникнуть самому, либо попробовать организовать каким-то образом вытаскивание информации из Алексея (даже при наличии сопротивления).
Сложнее — если ресурсов нет.
Мне бы в первую очередь хотелось поговорить с Алексеем, чтобы, а) показать ему, что его job security в порядке и будет таковым; б) его ценят и любят за его экспертность и это так и останется даже если он будет делиться знаниями; в) понять его мотивы и попробовать придумать, как в них (и возможно ли) в них встроить идею о передаче знаний.
Если удастся договориться с Алексеем, то вытаскивание и распространение знаний станет уже его осознанной и прямой задачей и останется только помогать ему методологически и ресурсно. А если не удастся — надо попробовать найти способ аккуратно разойтись.
Я руководитель команды из 10 человек. Когда мой разработчик Алексей уходит в отпуск, куча вопросов "встаёт" до его возвращения, нет никого, кто был бы настолько же в курсе отдельных частей проекта. Разработчику это похоже очень нравится, на моё предложение, чтобы он кого-то научил, передал свои знания реагирует агрессивно. Что делать? Если будут проблемы — всех собак повесят на меня.
Ответы дали авторы каналов Уютный Адочек, Человек и машина и Scrum Master Notes
А мы ждём ваших вопросов в: https://forms.gle/sKyaEuqQMMyFJBxJ8
@scrummasters — Василий Зорин
Все сильно зависит от команды и установившегося статуса кво внутри. Я бы начал с совместной ретроспективы: послушайте, что беспокоит команду, видит ли она эту проблему. Если да - отлично, значит разработчики сами предложат решение, а “Алексею” будет трудно игнорировать мнение коллег. Если команда эту проблему на замечает или обходит стороной - инициируйте разговор самостоятельно, через обсуждение кейсов, которые произошли в результате этой “зависимости” от “Алексея” (задержка релиза из-за отпуска “Алексея”- хороший повод).
Никто лучше самой команды не может сказать, как именно организовать процесс передачи знаний, поэтому главное - это подсветить проблему команде. Если сложившиеся отношения внутри команды не позволяют открыто обсуждать эту проблему, то нужно потратить время на формирование доверия и командной отвественности за результат. Если времени на это нет - прийдется действовать директивно и избегать появления подобных “Алексеев” в будущем.
@manandthemachine — Карен Товмасян
Ох уж эти Всезнающие Алексеи!
Позволю предположить, что Алексей в конторе был задолго до %username%, иначе непонятно, как подчиненный смог выстроить такую политическую игру.
Не стоит просить кого-то заняться обучением других, это должно быть не просьбой, а задачей.
Если же человек не хочет выполнить такое поручение, то стоит задаться вопросом, не боится ли этот человек потерять ценность для команды и проекта/продукта? Я уверен, нормальная встреча 1-1 приоткроет завесу тайны.
Но предположим, что Леха-карьерист таким образом решил кого-то (вас) подсидеть, и поэтому контакт не налаживается. Решение в таком случае жесткое: уволить и принять удар.
Да, с собаками придется повозиться, но я не слышал ни об одном предприятии, которое закрылось из-за ухода ключевого сотрудника.
@lovely_it_hell — Цупко Игорь
Многое зависит от того, сколько у вас времени на решение этой проблемы и какие есть доп. ресурсы. Когда они есть – можно либо вникнуть самому, либо попробовать организовать каким-то образом вытаскивание информации из Алексея (даже при наличии сопротивления).
Сложнее — если ресурсов нет.
Мне бы в первую очередь хотелось поговорить с Алексеем, чтобы, а) показать ему, что его job security в порядке и будет таковым; б) его ценят и любят за его экспертность и это так и останется даже если он будет делиться знаниями; в) понять его мотивы и попробовать придумать, как в них (и возможно ли) в них встроить идею о передаче знаний.
Если удастся договориться с Алексеем, то вытаскивание и распространение знаний станет уже его осознанной и прямой задачей и останется только помогать ему методологически и ресурсно. А если не удастся — надо попробовать найти способ аккуратно разойтись.
#пятничное
Да, я добавил комменты!
Правила простые: уважаем друг друга, не оскорбляем, ведем себя по совести, по-христиански или по заветам других религий (в зависимости от ваших предпочтений).
Я постараюсь к вам не лезть, но если увижу что-то, что меня расстраивает, буду удалять и банить.
Да, я добавил комменты!
Правила простые: уважаем друг друга, не оскорбляем, ведем себя по совести, по-христиански или по заветам других религий (в зависимости от ваших предпочтений).
Я постараюсь к вам не лезть, но если увижу что-то, что меня расстраивает, буду удалять и банить.
#машины_разное
То ли выгорел, то ли с жиру бесился, но как-то я писал, что в технологической индустрии все самое интересное уже придумали.
Это не я, это все пандемия ваша дурацкая!
По рекомендации приятеля вступил в клуб Вастрика, а раз я несу кому-то деньги (целый доллар!), то хочу их отбить (целый доллар!!!). Вот так я и прочитал Ту Самую Статью Про Квантовые Компьютеры, увидел словосочетание "Отрицательная Вероятность", и теперь это словосочетание не дает мне покоя.
Собственно, к чему я это все? К тому, что можно по-разному чувствовать себя в индустрии и профессии, но мой личный кайф в ощущении себя глупым. А чем дальше поднимаешься по карьерной/профессиональной лестнице, тем меньше остается неизвестного.
И я сейчас не про known unknowns, я осведомлен, что есть машинное обучение, микрофронтенды, Rust и даже C++ - словом, все, что я и так не знаю и могу сесть изучать, но это "не то".
Интерес именно в unknown unknowns, особенно когда те перестают быть unknown. До отрицательной вероятности меня так взбудоражило только внутреннее устройство индустрии телевещания. Одни только digital assets с метаданными чего стоят.
То ли выгорел, то ли с жиру бесился, но как-то я писал, что в технологической индустрии все самое интересное уже придумали.
Это не я, это все пандемия ваша дурацкая!
По рекомендации приятеля вступил в клуб Вастрика, а раз я несу кому-то деньги (целый доллар!), то хочу их отбить (целый доллар!!!). Вот так я и прочитал Ту Самую Статью Про Квантовые Компьютеры, увидел словосочетание "Отрицательная Вероятность", и теперь это словосочетание не дает мне покоя.
Собственно, к чему я это все? К тому, что можно по-разному чувствовать себя в индустрии и профессии, но мой личный кайф в ощущении себя глупым. А чем дальше поднимаешься по карьерной/профессиональной лестнице, тем меньше остается неизвестного.
И я сейчас не про known unknowns, я осведомлен, что есть машинное обучение, микрофронтенды, Rust и даже C++ - словом, все, что я и так не знаю и могу сесть изучать, но это "не то".
Интерес именно в unknown unknowns, особенно когда те перестают быть unknown. До отрицательной вероятности меня так взбудоражило только внутреннее устройство индустрии телевещания. Одни только digital assets с метаданными чего стоят.
vas3k.blog
Квантовый Компьютер
None
#машины_разное
По долгу (уже новой) службы мне приходится иметь дело с PCI-DSS - набором регуляторных требований к программным продуктам, которые хранят и/или обрабатывают информацию с платежных карт.
У PCI есть одно интересное требование, которое в упрощенной форме гласит: "разработчики не могут разворачивать свой код в production". Это очень интересное требование, потому что под "разработчика" может попасть каждый, кто вносит изменения в кодовую базу, попадающую под PCI.
Иными словами, я не имею права катить изменение, даже если я изменил пару строчек в конфигурационном файле. Пытаться спрятать изменение смысла нет - все есть в системе контроля версий.
Поэтому PCI сам собой вносит небольшой silo - в цепочке поставки обязательно должна быть Кнопка Валидации, которую должен нажать Специальный Уполномоченный Человек.
Не сказать, что это сильно влияет на скорость доставки, если только не гореть желанием катиться 20-30 раз в день, и есть надежная интеграционная среда - в таком случае можно собирать изменения и катиться раз в неделю, соблюдая все ритуалы.
Впрочем, энтузиасты находят несколько способов обходить требование не в ущерб скорости - от того, что дежурный инженер на низком старте стоит у кнопки "разрешить релиз", до клонирования кодовой базы и выкатки, как автоматизированной части цепочки поставки.
По долгу (уже новой) службы мне приходится иметь дело с PCI-DSS - набором регуляторных требований к программным продуктам, которые хранят и/или обрабатывают информацию с платежных карт.
У PCI есть одно интересное требование, которое в упрощенной форме гласит: "разработчики не могут разворачивать свой код в production". Это очень интересное требование, потому что под "разработчика" может попасть каждый, кто вносит изменения в кодовую базу, попадающую под PCI.
Иными словами, я не имею права катить изменение, даже если я изменил пару строчек в конфигурационном файле. Пытаться спрятать изменение смысла нет - все есть в системе контроля версий.
Поэтому PCI сам собой вносит небольшой silo - в цепочке поставки обязательно должна быть Кнопка Валидации, которую должен нажать Специальный Уполномоченный Человек.
Не сказать, что это сильно влияет на скорость доставки, если только не гореть желанием катиться 20-30 раз в день, и есть надежная интеграционная среда - в таком случае можно собирать изменения и катиться раз в неделю, соблюдая все ритуалы.
Впрочем, энтузиасты находят несколько способов обходить требование не в ущерб скорости - от того, что дежурный инженер на низком старте стоит у кнопки "разрешить релиз", до клонирования кодовой базы и выкатки, как автоматизированной части цепочки поставки.
Forwarded from Уютный IT адочек
Friendly Asked Questions #3 — про уровень зарплат
Почему мы платим разные зарплаты сотрудникам на удаленке? У них одинаковые должности и обязанности, но один находится дома в Москве, а другой дома в Саратове.
Ответы дали авторы каналов Уютный Адочек, DocOps, Человек и Машина, Евгений Потапов
А мы ждём ваших вопросов в: https://forms.gle/sKyaEuqQMMyFJBxJ8
Евгений Потапов (канал @eapotapov_channel)
Платить на удалёнке разные зарплаты для разных регионов выглядит странной затеей в 2021 году. Такой тренд был давно (и не только в РФ), когда можно было в регионах с более низкими зарплатами нанимать дешёвые кадры, но, имхо, сейчас ситуация уже сильно изменилась и рынок сформирован компаниями, которые платят универсальную зарплату без привязки к региону.
Карен Товмасян (канал @manandthemachine)
Очень хороший вопрос! Тема скользкая и несправедливая, но зарплата чаще всего строится не на базе выполняемой работы, но по средней зарплате по городу/региону.
Поэтому даже приехав из уездного города N, где зарплата была 30к, в Первопрестольную, то ценник сразу обретает нолик с конца, что работает и в обратную сторону. Не вы первый задаетесь этим вопросом, кстати. 😉
Ник Волынкин (канал @docops)
Не вижу хорошего ответа на этот вопрос, работодатель имеет возможность так делать, потому что информация о зарплатах закрыта. Нет принципа общей справедливости, и в итоге всё сводится к тому, как люди сами себя продали.
Однако, может быть дело не в удалёнке, а у сотрдуников разные скиллы и полезность.
Цупко Игорь (канал @lovely_it_hell)
Я видел, как люди, которых одинаково оценивают по скиллам, получают з/п отличающуюся в полтора-два раза. Просто за счёт региона, степени наглости самого сотрудника и того, в какой команде он оказался.
Владелец компании не был заинтересован отдавать его деньги. Вслух он говорил, что будет повышать зарплаты и поможет стать людям миллионерами, но реальные поступки говорили красноречивее 🙂
Я думаю, что разные зарплаты платят потому, что могут и потому, что это выгодно. Поступать так или нет — на совести тех, кто распоряжается деньгами.
Почему мы платим разные зарплаты сотрудникам на удаленке? У них одинаковые должности и обязанности, но один находится дома в Москве, а другой дома в Саратове.
Ответы дали авторы каналов Уютный Адочек, DocOps, Человек и Машина, Евгений Потапов
А мы ждём ваших вопросов в: https://forms.gle/sKyaEuqQMMyFJBxJ8
Евгений Потапов (канал @eapotapov_channel)
Платить на удалёнке разные зарплаты для разных регионов выглядит странной затеей в 2021 году. Такой тренд был давно (и не только в РФ), когда можно было в регионах с более низкими зарплатами нанимать дешёвые кадры, но, имхо, сейчас ситуация уже сильно изменилась и рынок сформирован компаниями, которые платят универсальную зарплату без привязки к региону.
Карен Товмасян (канал @manandthemachine)
Очень хороший вопрос! Тема скользкая и несправедливая, но зарплата чаще всего строится не на базе выполняемой работы, но по средней зарплате по городу/региону.
Поэтому даже приехав из уездного города N, где зарплата была 30к, в Первопрестольную, то ценник сразу обретает нолик с конца, что работает и в обратную сторону. Не вы первый задаетесь этим вопросом, кстати. 😉
Ник Волынкин (канал @docops)
Не вижу хорошего ответа на этот вопрос, работодатель имеет возможность так делать, потому что информация о зарплатах закрыта. Нет принципа общей справедливости, и в итоге всё сводится к тому, как люди сами себя продали.
Однако, может быть дело не в удалёнке, а у сотрдуников разные скиллы и полезность.
Цупко Игорь (канал @lovely_it_hell)
Я видел, как люди, которых одинаково оценивают по скиллам, получают з/п отличающуюся в полтора-два раза. Просто за счёт региона, степени наглости самого сотрудника и того, в какой команде он оказался.
Владелец компании не был заинтересован отдавать его деньги. Вслух он говорил, что будет повышать зарплаты и поможет стать людям миллионерами, но реальные поступки говорили красноречивее 🙂
Я думаю, что разные зарплаты платят потому, что могут и потому, что это выгодно. Поступать так или нет — на совести тех, кто распоряжается деньгами.
#машины_разное
Гвидо ван Россум, отец Python и вернувшийся из пенсии в Microsoft инженер, поставил перед собой очень амбициозную цель, а именно - увеличить производительность своего детища аж в два раза.
Речь конечно же не про сам язык, а про его основной движок CPython.
Новость довольно большая, следить я за этим буду пристально.
Впрочем, мой интерес чисто технический, что именно собираются сделать для увеличения производительности? Поэтому я открыл PEP-554, автор которого отдельно отмечает, что не намерен решать проблему GIL (но мы-то с вами все понимаем).
Способов обойти GIL и так хватает: от использования multiprocessing до других движков, например PyPy.
PEP-554 интересен тем, что предлагает по-новому взглянуть на sub-интерпретаторы и (пере)изобрести конкурентное программирование. Причем пользоваться эти можно будет донельзя легко. Вот кусок кода, прямиком из PEP:
Но не это самое “вкусное”. Если пройти дальше по предложению до раздела “About Subinterpreters”, то можно увидеть слово, которое очень знакомо разработчикам на Golang - каналы! По словам автора Предложения, каналы будут единственным объектом, доступным всем интерпретаторам, а обмен объектов будут проходить через них.
Подытожим: в версии 3.11 собираются ускорить CPython, и поможет нам в этом новый модуль interpreters, который имплементирует конкурентное программирование, схожее с Golang.
Вот что скучная пенсия с людьми делает!
Гвидо ван Россум, отец Python и вернувшийся из пенсии в Microsoft инженер, поставил перед собой очень амбициозную цель, а именно - увеличить производительность своего детища аж в два раза.
Речь конечно же не про сам язык, а про его основной движок CPython.
Новость довольно большая, следить я за этим буду пристально.
Впрочем, мой интерес чисто технический, что именно собираются сделать для увеличения производительности? Поэтому я открыл PEP-554, автор которого отдельно отмечает, что не намерен решать проблему GIL (но мы-то с вами все понимаем).
Способов обойти GIL и так хватает: от использования multiprocessing до других движков, например PyPy.
PEP-554 интересен тем, что предлагает по-новому взглянуть на sub-интерпретаторы и (пере)изобрести конкурентное программирование. Причем пользоваться эти можно будет донельзя легко. Вот кусок кода, прямиком из PEP:
interp = interpreters.create()
print('before')
interp.run('print("during")')
print('after’)Но не это самое “вкусное”. Если пройти дальше по предложению до раздела “About Subinterpreters”, то можно увидеть слово, которое очень знакомо разработчикам на Golang - каналы! По словам автора Предложения, каналы будут единственным объектом, доступным всем интерпретаторам, а обмен объектов будут проходить через них.
Подытожим: в версии 3.11 собираются ускорить CPython, и поможет нам в этом новый модуль interpreters, который имплементирует конкурентное программирование, схожее с Golang.
Вот что скучная пенсия с людьми делает!
#машины_разное
Однажды я спросил у кандидата про отличие между мониторингом (monitoring) и наблюдаемостью (observability). Не получив удовлетворительного ответа, я позже поинтересовался у своих коллег-приятелей - и оказалось, что тема непрозрачная и не до конца понятная.
Оно и очевидно, observability попала в “тренды” незадолго после появления eBPF, и к кому бы не сходить за ее определением, как к одному из пионеров индустрии… Однако, получаем больше вопросов, чем ответов.
По сути, что одно, что второе имеют схожее определение, да и решают одну и ту же задачу - знать о состоянии системы.
Отличий как таковых и нет - наблюдаемость дополняет мониторинг. Если мониторинг опирается на определенные метрики, глядя на которые можно понять, как чувствует себя программный продукт, в инструментарий observability еще входят обработка логов и отслеживание запросов (tracing).
Что позволяет “наблюдать” не только за одной системой, но и ее связкой с остальными.
Однажды я спросил у кандидата про отличие между мониторингом (monitoring) и наблюдаемостью (observability). Не получив удовлетворительного ответа, я позже поинтересовался у своих коллег-приятелей - и оказалось, что тема непрозрачная и не до конца понятная.
Оно и очевидно, observability попала в “тренды” незадолго после появления eBPF, и к кому бы не сходить за ее определением, как к одному из пионеров индустрии… Однако, получаем больше вопросов, чем ответов.
По сути, что одно, что второе имеют схожее определение, да и решают одну и ту же задачу - знать о состоянии системы.
Отличий как таковых и нет - наблюдаемость дополняет мониторинг. Если мониторинг опирается на определенные метрики, глядя на которые можно понять, как чувствует себя программный продукт, в инструментарий observability еще входят обработка логов и отслеживание запросов (tracing).
Что позволяет “наблюдать” не только за одной системой, но и ее связкой с остальными.
Спорим, это снова Cloudflare?
UPD: Ан нет, на этот раз возможно Fastly.
UPD: Ан нет, на этот раз возможно Fastly.
#машины_aws
Незаметной новостью прошел большой и серьезный анонс - AWS KMS, сервис, предоставляющий ключи для (де-)шифрования, научился реплицировать ключи между регионами.
Функциональность эта очень полезная, поскольку сильно сэкономит время на те же кросс-региональные операции, сократив количество действий. Посудите сами.
Отправить бекап диска виртуальной машины или базы данных - задача частая и вполне стандартная. И шифровать эти самые бекапы тоже идея не из глупых. Шифрование делается с помощью мастер-ключей конкретного аккаунта - Customer Master Key или CMK.
Так вот раньше (а точнее до вчерашнего анонса) эти ключи были уникальны на регион, что означало следующую цепочку действий.
1. Делаем нешифрованный бекап
2. Копируем в другой регион
3. Шифруем
Дела были еще хуже, если бекап автоматически шифровался:
1. Дешифруем шифрованный бекап
2. Копируем
3. Шифруем!
Стоит ли добавить, что помимо потраченного времени на дешифрование/шифрование, каждый поход в KMS за ключом стоит денег и отражается в счете?
Теперь таких хитростей делать не придется, что хорошо, но есть и небольшой деготь. Уникальность ключа на регион сама собой ограничивала blast radius - злоумышленник, получив доступ к ключу в конкретном регионе, мог открыть сундучки в только нем же. С этим нововведением есть риск подарить злодею ключик от сундучков по всему земному шарику (в пределах одного аккаунта, конечно же).
Впрочем, у AWS'а 1000 и 1 способ от таких историй защищаться.
Незаметной новостью прошел большой и серьезный анонс - AWS KMS, сервис, предоставляющий ключи для (де-)шифрования, научился реплицировать ключи между регионами.
Функциональность эта очень полезная, поскольку сильно сэкономит время на те же кросс-региональные операции, сократив количество действий. Посудите сами.
Отправить бекап диска виртуальной машины или базы данных - задача частая и вполне стандартная. И шифровать эти самые бекапы тоже идея не из глупых. Шифрование делается с помощью мастер-ключей конкретного аккаунта - Customer Master Key или CMK.
Так вот раньше (а точнее до вчерашнего анонса) эти ключи были уникальны на регион, что означало следующую цепочку действий.
1. Делаем нешифрованный бекап
2. Копируем в другой регион
3. Шифруем
Дела были еще хуже, если бекап автоматически шифровался:
1. Дешифруем шифрованный бекап
2. Копируем
3. Шифруем!
Стоит ли добавить, что помимо потраченного времени на дешифрование/шифрование, каждый поход в KMS за ключом стоит денег и отражается в счете?
Теперь таких хитростей делать не придется, что хорошо, но есть и небольшой деготь. Уникальность ключа на регион сама собой ограничивала blast radius - злоумышленник, получив доступ к ключу в конкретном регионе, мог открыть сундучки в только нем же. С этим нововведением есть риск подарить злодею ключик от сундучков по всему земному шарику (в пределах одного аккаунта, конечно же).
Впрочем, у AWS'а 1000 и 1 способ от таких историй защищаться.
Amazon
Multi-Region keys in AWS KMS - AWS Key Management Service
Learn how to create and use multi-Region keys
#машины_разное
Навеянная историей грандиозного рефакторинга Lingualeo (поищите в сети, если не застали), интересная находка.
Интересна она в том числе и тем, что найти ее оказалось не так-то и просто. Не удивлюсь, если Гугл плохо индексирует запросы о продуктах, написанных на Haskell.
P.S. Для веб-хипстеров есть и GraphQL-версия.
Навеянная историей грандиозного рефакторинга Lingualeo (поищите в сети, если не застали), интересная находка.
Интересна она в том числе и тем, что найти ее оказалось не так-то и просто. Не удивлюсь, если Гугл плохо индексирует запросы о продуктах, написанных на Haskell.
P.S. Для веб-хипстеров есть и GraphQL-версия.
GitHub
GitHub - PostgREST/postgrest: REST API for any Postgres database
REST API for any Postgres database. Contribute to PostgREST/postgrest development by creating an account on GitHub.
#машины_aws
На той неделе AWS выкатил интересное, но спорное по полезности обновление.
Правила Security Group обзавелись собственными идентификаторами, а значит стали де факто отдельными ресурсами. Базово о практическом применении можно прочитать здесь.
В целом, у новой функциональности хватает плюсов. Во-первых, если одно правило используется несколькими SG одновременно, то не придется больше ходить и везде их менять (до этого “общее” правило цепляли на отдельную SG и назначали на все нужные области сети). Во-вторых, это упрощает управление, если за правило отвечает другая группа - теперь она может сама поменять, что нужно, а не заводить, ну не знаю, Change Request. В-третьих, это безусловно хорошая внутренняя оптимизация, которая положительно повлияет на квоты и лимиты (или нет).
Однако есть жирный минус - правила, пусть и со своими идентификаторами, все еще не живут без самой SG и заводить их отдельно нельзя. А бонус от изменения, описанный в примере выше, применим к тем, кто по какой-то причине управляет своей инфраструктурой только через Bash и awscli.
Как будто хотя бы одна маломальски серьезная организация так делает.
К сожалению, новая “фича” выглядит сыроватой, а анонс словно сделан в спешке. Тем не менее, если правила смогут стать полноценным независимыми сущностями и попадут в RAM, то просторов для использования много.
На той неделе AWS выкатил интересное, но спорное по полезности обновление.
Правила Security Group обзавелись собственными идентификаторами, а значит стали де факто отдельными ресурсами. Базово о практическом применении можно прочитать здесь.
В целом, у новой функциональности хватает плюсов. Во-первых, если одно правило используется несколькими SG одновременно, то не придется больше ходить и везде их менять (до этого “общее” правило цепляли на отдельную SG и назначали на все нужные области сети). Во-вторых, это упрощает управление, если за правило отвечает другая группа - теперь она может сама поменять, что нужно, а не заводить, ну не знаю, Change Request. В-третьих, это безусловно хорошая внутренняя оптимизация, которая положительно повлияет на квоты и лимиты (или нет).
Однако есть жирный минус - правила, пусть и со своими идентификаторами, все еще не живут без самой SG и заводить их отдельно нельзя. А бонус от изменения, описанный в примере выше, применим к тем, кто по какой-то причине управляет своей инфраструктурой только через Bash и awscli.
Как будто хотя бы одна маломальски серьезная организация так делает.
К сожалению, новая “фича” выглядит сыроватой, а анонс словно сделан в спешке. Тем не менее, если правила смогут стать полноценным независимыми сущностями и попадут в RAM, то просторов для использования много.
#жиза
Есть две одержимости, которые я не пойму, да и не приму:
• Одержимость механическими клавиатурами
• Одержимость когнитивной эффективностью вне работы
Причем с механическими клавиатурами все более менее понятно. Раз уж айтишники теперь ремесленники, то и молоток должен быть подходящий. Вопросов больше к пострадавшим от профдеформации настолько, что хотят решать бытовые задачи за O(logn).
Я сейчас о тех, кто стремится к жесткому минимализму вещей в доме, мутит одинаковый гардероб дома (аля одного цвета майки, рубашки, брюки), мутит полнейшую цифровизацию комуналки - в целом все, чтобы лишний раз не напрячь мозг в субботний день.
Я могу понять, когда это делает в силу лени - к примеру, когда люди делают автоплатеж той же коммуналки, а под конец года сводят дебет с кредитом и корректируют сумму.
Но чего я не могу понять, так это бессмысленной, на мой взгляд, экономии умственных сил. Ну то есть, что произойдет, если 5 минут потратить на выбор блюда на завтрак или одежды? Мозг лопнет? "Таски" не закроются?
Стоит ли настолько скупиться мозгом для себя, чтобы отдать его с концами на работу? Зачем копировать повадки Джобса и Цукерберга?
Я открыт к обратной связи, так что в комменты приглашаются сторонники персональной эффективности.
Есть две одержимости, которые я не пойму, да и не приму:
• Одержимость механическими клавиатурами
• Одержимость когнитивной эффективностью вне работы
Причем с механическими клавиатурами все более менее понятно. Раз уж айтишники теперь ремесленники, то и молоток должен быть подходящий. Вопросов больше к пострадавшим от профдеформации настолько, что хотят решать бытовые задачи за O(logn).
Я сейчас о тех, кто стремится к жесткому минимализму вещей в доме, мутит одинаковый гардероб дома (аля одного цвета майки, рубашки, брюки), мутит полнейшую цифровизацию комуналки - в целом все, чтобы лишний раз не напрячь мозг в субботний день.
Я могу понять, когда это делает в силу лени - к примеру, когда люди делают автоплатеж той же коммуналки, а под конец года сводят дебет с кредитом и корректируют сумму.
Но чего я не могу понять, так это бессмысленной, на мой взгляд, экономии умственных сил. Ну то есть, что произойдет, если 5 минут потратить на выбор блюда на завтрак или одежды? Мозг лопнет? "Таски" не закроются?
Стоит ли настолько скупиться мозгом для себя, чтобы отдать его с концами на работу? Зачем копировать повадки Джобса и Цукерберга?
Я открыт к обратной связи, так что в комменты приглашаются сторонники персональной эффективности.
#машины_разное #люди
Недавно на просторах тележки я вступил в одну минидискуссию о проблемах эксплуатации DynamoDB там, где можно было эксплуатировать реляционную БД. Оставим тему за скобками, к этому посту она не имеет отношения.
Ни для кого не секрет, что в проектировании систем, что за час на собеседовании, что за месяц на работе необходимо зарисовать имплементацию требований и предусмотреть множество сценариев, в основном нежелательных - отказ узла, дупликация данных, какие-то гарантии, регуляции.
Предусмотреть все и вся не получится. Будущие хотелки где-то в будущем (возможно далеком), внезапные ограничения там же по соседству. Можно попытаться обеспечить 5 девяток при отказе всех датацентров сразу, но такой дизайн никогда не увидит свет, не говоря уже о выходе системы в промышленную эксплуатацию.
Поэтому в самом начале стоит следовать KISS и учитывать только те требования и ограничения, которые могут наступить до, в момент и через год с начала выхода в прод. Тут уже на многие вопросы “какую СУБД возьмем” или “на каком языке будем писать” будет ответ “на каком можем и быстро”.
Не переживайте, через несколько лет новичок-карьерист перепишет вашу систему на Rust и занесет сэкономленные наносекунды на запрос в резюме.
Чтобы этому новичку-карьеристу было проще это сделать, а вам, как автору оригинальной системы, не стыдно, заводятся Записи Архитектурных Решений (ADR). В некоторых местах используются старые добрые RFC.
Кстати, дайте знать, если тема архитектурных решений интересная, могу рассказать подробнее.
Другое дело, когда нужно решать задачи ПЛАНЕТАРНОГО МАСШТАБА. Впрочем, это тема для другого разговора.
Недавно на просторах тележки я вступил в одну минидискуссию о проблемах эксплуатации DynamoDB там, где можно было эксплуатировать реляционную БД. Оставим тему за скобками, к этому посту она не имеет отношения.
Ни для кого не секрет, что в проектировании систем, что за час на собеседовании, что за месяц на работе необходимо зарисовать имплементацию требований и предусмотреть множество сценариев, в основном нежелательных - отказ узла, дупликация данных, какие-то гарантии, регуляции.
Предусмотреть все и вся не получится. Будущие хотелки где-то в будущем (возможно далеком), внезапные ограничения там же по соседству. Можно попытаться обеспечить 5 девяток при отказе всех датацентров сразу, но такой дизайн никогда не увидит свет, не говоря уже о выходе системы в промышленную эксплуатацию.
Поэтому в самом начале стоит следовать KISS и учитывать только те требования и ограничения, которые могут наступить до, в момент и через год с начала выхода в прод. Тут уже на многие вопросы “какую СУБД возьмем” или “на каком языке будем писать” будет ответ “на каком можем и быстро”.
Не переживайте, через несколько лет новичок-карьерист перепишет вашу систему на Rust и занесет сэкономленные наносекунды на запрос в резюме.
Чтобы этому новичку-карьеристу было проще это сделать, а вам, как автору оригинальной системы, не стыдно, заводятся Записи Архитектурных Решений (ADR). В некоторых местах используются старые добрые RFC.
Кстати, дайте знать, если тема архитектурных решений интересная, могу рассказать подробнее.
Другое дело, когда нужно решать задачи ПЛАНЕТАРНОГО МАСШТАБА. Впрочем, это тема для другого разговора.
#машины_разное #люди
Пару слов об архитектурных решениях.
Для начала давайте определимся с терминологией:
ADR - реестр архитектурных решений, то есть архив всех архитектурных и дизайн документов с историей.
RFC - request for comments, он же (русское значение мне больше по душе) рабочее предложение - документ, описывающий новое решение или радикальное изменение текущего.
Многие из вас слышали про RFC под разными номерами, и ассоциируете этот акроним только с сетевыми штучками. Это в корне неверно (RFC есть даже по UTF-8 и SQL), и в то же время верно - ведь его придумали не абы кто, а отцы-основатели интернета IETF.
Несложно догадаться, что ADR хранит в себе один и более RFC, как принятых, так и (что еще важнее) непринятых - быть им наукой для новичков, которые с полпинка хотят внедрить вундервафлю и получить солидный бонус.
А что касается RFC, то порядок и формат оформления, рассмотрение и принятие оного разнится от организации к организации. Однако некоторые постулаты неизменны.
Во-первых, RFC обладают своими уровнями: какие-то преподносят изменения, пусть и радикальные, в одно-два места, другие же трансформируют инженерные процессы или организацию в целом. Для сравнения: 1) развернуть один из продуктов на облачном провайдере или 2) перенести все нагрузки в K8s. Идея 1 по масштабу значительно меньше Идеи 2, а значит и рассматривать ее будет меньше людей (об этом позже).
Во-вторых, RFC должны включать в себя: предысторию, ставшую причиной идеи; обоснование; известные ограничения, принятые к сведению; полностью дизайн; детали имплементации. Все это необходимо, чтобы "продать" идею, да и в первую очередь для себя - проще будет задачи нарезать.
В-третьих, каждый RFC проходит приемную комиссию, состоящую из высокогрейдовых инженеров из разных групп: как бизнесовой, так и инфобез, инфраструктурщины, сетей, и т.д. Количество подписей и пар глаз, критически смотрящих на ваше творение, зависит от того самого уровня RFC. Приемка нужна, чтобы убедиться, что нужного инструмента или решения уже нет на месте, ну и чтобы вы учитывали все-все-все нюансы.
Ну и самое интересное: после принятия решения - то есть когда RFC подписано всеми, кем надо, и готово к имплементации - оспаривать его уже нельзя. Можно изменить что-то на уровне ниже, но если вы договорились тащить K8s, на полпути переходить на Nomad не выйдет.
Даже если очень хочется.
Пару слов об архитектурных решениях.
Для начала давайте определимся с терминологией:
ADR - реестр архитектурных решений, то есть архив всех архитектурных и дизайн документов с историей.
RFC - request for comments, он же (русское значение мне больше по душе) рабочее предложение - документ, описывающий новое решение или радикальное изменение текущего.
Многие из вас слышали про RFC под разными номерами, и ассоциируете этот акроним только с сетевыми штучками. Это в корне неверно (RFC есть даже по UTF-8 и SQL), и в то же время верно - ведь его придумали не абы кто, а отцы-основатели интернета IETF.
Несложно догадаться, что ADR хранит в себе один и более RFC, как принятых, так и (что еще важнее) непринятых - быть им наукой для новичков, которые с полпинка хотят внедрить вундервафлю и получить солидный бонус.
А что касается RFC, то порядок и формат оформления, рассмотрение и принятие оного разнится от организации к организации. Однако некоторые постулаты неизменны.
Во-первых, RFC обладают своими уровнями: какие-то преподносят изменения, пусть и радикальные, в одно-два места, другие же трансформируют инженерные процессы или организацию в целом. Для сравнения: 1) развернуть один из продуктов на облачном провайдере или 2) перенести все нагрузки в K8s. Идея 1 по масштабу значительно меньше Идеи 2, а значит и рассматривать ее будет меньше людей (об этом позже).
Во-вторых, RFC должны включать в себя: предысторию, ставшую причиной идеи; обоснование; известные ограничения, принятые к сведению; полностью дизайн; детали имплементации. Все это необходимо, чтобы "продать" идею, да и в первую очередь для себя - проще будет задачи нарезать.
В-третьих, каждый RFC проходит приемную комиссию, состоящую из высокогрейдовых инженеров из разных групп: как бизнесовой, так и инфобез, инфраструктурщины, сетей, и т.д. Количество подписей и пар глаз, критически смотрящих на ваше творение, зависит от того самого уровня RFC. Приемка нужна, чтобы убедиться, что нужного инструмента или решения уже нет на месте, ну и чтобы вы учитывали все-все-все нюансы.
Ну и самое интересное: после принятия решения - то есть когда RFC подписано всеми, кем надо, и готово к имплементации - оспаривать его уже нельзя. Можно изменить что-то на уровне ниже, но если вы договорились тащить K8s, на полпути переходить на Nomad не выйдет.
Даже если очень хочется.
#люди
Отложим на секунду всякие архитектурно-инженерные изыскания и поговорим еще раз о работе с людьми. Конкретно об отказах и как отказывать другим.
В бытность активного карьеростроения и поисков себя я старался браться за абсолютно каждый движ, как вылезший из сознания, так и навязанный извне. В один момент стало ясно, что энергии со временем больше не становится, думалка работает не так шустро, да и чем выше по ступеням, тем больше надо следовать закону Парето (80/20) - то есть работать над чем-то меньшим, что возымеет больший эффект.
Как такие проекты находить, планировать и делать - разговор отдельный. Насущная же проблема остается - к вам, чем бы вы не занимались, будут приходить люди и предлагать всякое. Приходить могут извне и изнутри, идеи могут быть от мала до велика, платно или задарма.
Поначалу может показаться, что отказываться нужно от откровенной дичи или бесплатной работы, но это далеко не так. От некоторых, даже очень интересных затей нужно отказываться, потому что вы у себя один такой, а вот предлагающий преследует свои интересы и цели, достижение которых принесет выгоду ему, но не вам. А значит браться надо только за то, что нужно в первую очередь вам самим.
Отказывать же нужно аргументированно и аккуратно - глобус маленький, и никогда не знаешь, с кем придется иметь дела в будущем. Лучший способ - честно и прозрачно объяснить почему вы готовы за что-то браться. Мне иногда помогает How to say No, чтобы найти нужные слова, но усложнять нет необходимости.
Нет времени, и вы загружены? Так и говорите.
Не работаете бесплатно? Ничего плохого в этом нет.
Не интересуетесь темой? Явно укажите и перечислите то, что вам реально интересно (авось, подкинут что покруче).
Просто задолбались, выгорели и едете кукухой? Со всеми бывает.
Понятное дело, написанное выше про профессиональные отношения и работу. В личной жизни мы часто делаем то, чего не хотим, потому что любим и дорожим людьми, для которых это делаем. Как отказывать им - тема наиболее тонкая, сложная и индивидуальная, и писать о ней я, само собой, не возьмусь.
Отложим на секунду всякие архитектурно-инженерные изыскания и поговорим еще раз о работе с людьми. Конкретно об отказах и как отказывать другим.
В бытность активного карьеростроения и поисков себя я старался браться за абсолютно каждый движ, как вылезший из сознания, так и навязанный извне. В один момент стало ясно, что энергии со временем больше не становится, думалка работает не так шустро, да и чем выше по ступеням, тем больше надо следовать закону Парето (80/20) - то есть работать над чем-то меньшим, что возымеет больший эффект.
Как такие проекты находить, планировать и делать - разговор отдельный. Насущная же проблема остается - к вам, чем бы вы не занимались, будут приходить люди и предлагать всякое. Приходить могут извне и изнутри, идеи могут быть от мала до велика, платно или задарма.
Поначалу может показаться, что отказываться нужно от откровенной дичи или бесплатной работы, но это далеко не так. От некоторых, даже очень интересных затей нужно отказываться, потому что вы у себя один такой, а вот предлагающий преследует свои интересы и цели, достижение которых принесет выгоду ему, но не вам. А значит браться надо только за то, что нужно в первую очередь вам самим.
Отказывать же нужно аргументированно и аккуратно - глобус маленький, и никогда не знаешь, с кем придется иметь дела в будущем. Лучший способ - честно и прозрачно объяснить почему вы готовы за что-то браться. Мне иногда помогает How to say No, чтобы найти нужные слова, но усложнять нет необходимости.
Нет времени, и вы загружены? Так и говорите.
Не работаете бесплатно? Ничего плохого в этом нет.
Не интересуетесь темой? Явно укажите и перечислите то, что вам реально интересно (авось, подкинут что покруче).
Просто задолбались, выгорели и едете кукухой? Со всеми бывает.
Понятное дело, написанное выше про профессиональные отношения и работу. В личной жизни мы часто делаем то, чего не хотим, потому что любим и дорожим людьми, для которых это делаем. Как отказывать им - тема наиболее тонкая, сложная и индивидуальная, и писать о ней я, само собой, не возьмусь.
Starterstory
How To Say No
Saying no is hard, but it's also essential for your sanity. Here are some templates for how to say no - so you can take back your life.