Cоздает внутренний конфликт интересов и может закончиться не сильно хорошо.
Почему "внешний" конфликт интересов лучше "внутреннего"? Я же не просто так привёл пример про DevOps. Я застал времена, когда продуктовых разработчиков премировали за изменения, а системных администраторов за отсутствие проишествий. Надо ли говорить, что изменения в коде -- главный источник проишествий в проде, который системные администраторы едва ли контролируют? Продуктовым разработчикам же часто не хватало мотивации понять боль ops коллег, они жили несколько в разных загонах и, порой, друг друга не понимали.
В итоге я регулярно наблюдал встречи, когда продуктовая разработка просит ускорить релизы, а эксплуатация их тормозит, как может. Когда разработка хочет добавить побольше компонентов-зависимостей, а сисадмины стараются умерить их пыл.
Глядя на то, что произошло после, мне очевидно, насколько продуктивной оказалось замена устаревшей командной топологии с "внешнего" на "внутренний" конфликт интересов, а именно, на разработчиков, которые сами релизят и сами просыпаются по ночам от звонков мониторинга и платформенную команду, которая позволяет им делать всё это, не разрываясь от когнитивной нагрузки.
Теперь разработчки сами решают (в том числе с помощью методик вроде SRE Error Budget), когда надо начинать разгребать влияющий на надёжность технический долг, временно переключив деятельность с разработки бизнес-фич, на стабилизацию продуктов).
Люблю это как пример провального перевода. Оригинальное название Dark Fields в данном контексте скорее переводится как "белые пятна" или как "неизведанные области".
Если авторы измеряют ее в штуках нанятых программистов в единицу времени, то у меня для них неприятные новости
Увы, такими темпами можно вообще отказаться от измерения чего-либо.
Это примерно как отказаться всех тестов и замеров производительности у отдельных компонентов сложной программной системы, в пользу исключительно e2e тестов и замеров всей системы в сборе. Правда в том, что нужно и то и другое для разных целей.
Для начала оговорим, что, судя по контексту, тут речь про рекрутеров (это лишь одна HR ролей). Они бывают штатные и внештатные. Возьмём для простоты внештатных и посмотрим на систему оплаты их труда. Общепринятая рыночная практика -- внештатный рекрутер получает деньги, если приведённый ими кандидат принял предложение о работе.
За всех остальных приведённых кандидатов внештатный рекрутер не получает ничего.
За дальнейшую судьбу сотрудника в компании внештатный рекрутер обычно не отвечает -- его задача привести кандидатов, а дальше уже ответственность перекладывается на нанимающих сотрудников компании.
Таким образом, видим, что внештатный рекрутер отвечает только за начальный этап воронки набора сотрудников. Первая наивная мысль -- раз платят за нанятых сотрудников (поштучно или взвешенно в зависимости от размера компенсации или уровня квалификации), то в интересах рекрутера навалить в эту воронку как можно больше кандидатов. Однако, такой подход по факту не работает: если внештатный рекрутер начинает приводить неподходящих кандидатов и, как следствие, конверсия кандидатов в сотрудники снижается, порожняком нагружая сотрудников компании собеседованиями, то компания перестанет сотрудничать с этим рекрутером. Похожая история может произойти и с кандидатами, которые тоже обычно не заинтересованы бесплодно собеседоваться на неподходящие роли.
Вот и видим, что у внештатного рекрутера появляются естественным образом две метрики эффективности -- число приведённых кандидатов и их конверсия.
И компания будет готова заплатить больше тому внештатному рекрутеру, который сможет показать лучшие метрики.
Вот такими метриками эффективности и разделяются границы составных частей системы. И важно из замерять -- это базовый принцип декомпозиции, активно применямый в науке для исследований и в управлении сложными системами.
Таким же образом можно замерять эффективность любой сколь-либо повторяемой и стандартизируемой работы. И мы знаем, что заметная часть разработчиков -- формошлёпы и CRUD-оделы, чья работа не подразумевает значительной исследовательской работы с большихм коэффециентом неопределённости.
vmware == вендорлок. Что, если завтра они поднимут цену в 10 раз или технологически свернут не туда? Или перестанут оказывать услуги для клиентов в определённой юрисдикции?
Я застал пеереезд в vwmare на openstack в одной большой и известной организации году так в 2012. Даже тогда, во времена господства vmware в области виртуализации, это был прямо прорыв.
Насколько я понимаю, аналогия Event Notifications в Яндекс Облаке - Audit Trails.
Не совсем. Сбор аудитных логов есть отдельно от Event Notifications в AWS и GCP.
Суть Event Notifications в том, что на события в сервисе можно повесить свои кастомные обработчики. Например, запустить cloud serverless function / lambda.
Впрочем, допускаю, что эту же функциональность вполне можно самому реализовать на основе аудитных логов, которые придётся постоянно мониторить.
фейковые страницы авторизации для Microsoft Online
Пожалуйста, прекратите, называть аутентификацию авторизацией. Если так не нравится слово "аутентификация", можно писать "страница входа в учётную запись".
Хоть я и не Дмитрий, а иной чувак, отвечающий за инфраструктуру в другом стартапе, но могу рассказать на примере GCP. В GCP эту задачу решают аж три продукта: Apigee, Managed API Gateway и Managed Endpoints.
Предположим, мы хотим решать задачу монетизации API. То есть, чтобы не растаскивать специфическую логику по бекендам, API Gateway должен:
1) аутентифицировать пользователей, ходя в некоторую auth db с кешированием у себя
2) проверять статус оплаты -- некоторую метаинфу, взятую из биллинга
3) в зависимости от статуса -- возвращать на запросы ошибку или устраивать rate limiting (что тоже сводится к возврату ошибки в какой-то момент, вместо передачи запроса бекенду)
4) отправлять в биллинг статистику потребления в разбивке по пользователям в реальном времени
Apigee -- типичный кровавый энтерпрайз с развесистыми XML-конфигами и конскими ценами, купленный Google в 2015.
Он умеет делать перечисленное, но стоить это будет в минимальной конфирурации $30к в год (и оплата на год вперёд, договор и всё такое -- для стартапа прямо мечта) и всё равно придётся многое дописывать и допиливать. Да и не очень-то cloud-native решение, как ни странно -- IaaS для конфигурации всего это дело представлен почти незадокументированным плагином. Ни о чём вроде terraform провайдер мечтать не приходится.
Managed API Gateway -- чрезмерно минималистичный продукт, который только по сути маршрутизацию запросов по разным бекендам умеет делать и очень кривую аутентификацию на статичных API-ключах. Никаких возможностей интеграции с биллином и условной логики нет. Ах да, ещё конфигурируется это всё исключительно на Swagger 2, про OpenAPI 3 они не слышали и внедрять не планируют.
Managed Endpoints -- похожая сущность на Managed API Gateway, разве что в основе взят Extensible Service Proxy v2 -- сборка Envoy, конфигурируемая через GCP-сервис управления конфигами.
В общем, так я и не смог решить встроенными GCP инструментами описанную задачу.
Поэтому пришлось отправиться в OpenSource и external SaaS миры, где, увы, в этом месте всё тоже оставляет желать лучшего -- прямо чтобы парой кликов заработал интегрированный с API Gateway портал API разработчика, где можно привязать карту для оплаты и смотреть отчёты биллинга -- с этим 3.5 компании пытаются что-то делать и скорее в зачаточном состоянии.
удивительно, как часто совпадения и ошибки могут выглядеть злонамеренными
Ну да, чистое же совпадение, что в единственной стране, где у Google есть конкурент на открытом рынке, диалог выбора поисковой системы в chromium based браузерах показываться не должен.
Ещё бы знать, что авторизация (от authority, буквально: уполномочивание) -- это и есть та самая "работа с пермишнами". А то, что в этой статье называется этим словом -- аутентификация (от authenticity, буквально: проверка подлинности).
И по этой же причине понятие "авторизоваться" (то есть, уполномочить себя) не имеет смысла.
И да, использование правильной терминологии -- важно и позволяет сэкономить время при обсуждении. По той причине, что нередко за эти две задачи отвечают разные независимые компоненты. И то, что проблемы с аутентификацией и авторизацией решаются разными способами.
Касательно "ВПО": напомню, чем "программа" отличается от ПО согласно ГОСТ 19781-90 и ISO/IEC 2382-1:1993 -- прилагаемой документацией. Они распространяли документацию? Если нет, то это "вредоносная программа", а не "ВПО".
Я активно использую GPU в контейнерах -- проблемы с этим нет, спасибо за это nvidia-container-runtime. Хотя с трудом представляю, зачем может пригодится GPU во время сборки -- разве что, для прогона тестов характерных.
И сборочные задачи (многие из которых довольно замысловатые) у меня все запускаются в контейнерах и пока ни потребности ни желания работать с хостовой не появлялось, потому и спрашиваю.
"Власти подумали-подумали и пришли к компаниям с простым условием: либо 60% времени ваши сотрудники ходят в офис и тратят там деньги, либо хрен вам, а не налоговые льготы"
Почему "внешний" конфликт интересов лучше "внутреннего"? Я же не просто так привёл пример про DevOps. Я застал времена, когда продуктовых разработчиков премировали за изменения, а системных администраторов за отсутствие проишествий. Надо ли говорить, что изменения в коде -- главный источник проишествий в проде, который системные администраторы едва ли контролируют? Продуктовым разработчикам же часто не хватало мотивации понять боль ops коллег, они жили несколько в разных загонах и, порой, друг друга не понимали.
В итоге я регулярно наблюдал встречи, когда продуктовая разработка просит ускорить релизы, а эксплуатация их тормозит, как может. Когда разработка хочет добавить побольше компонентов-зависимостей, а сисадмины стараются умерить их пыл.
Глядя на то, что произошло после, мне очевидно, насколько продуктивной оказалось замена устаревшей командной топологии с "внешнего" на "внутренний" конфликт интересов, а именно, на разработчиков, которые сами релизят и сами просыпаются по ночам от звонков мониторинга и платформенную команду, которая позволяет им делать всё это, не разрываясь от когнитивной нагрузки.
Теперь разработчки сами решают (в том числе с помощью методик вроде SRE Error Budget), когда надо начинать разгребать влияющий на надёжность технический долг, временно переключив деятельность с разработки бизнес-фич, на стабилизацию продуктов).
PM -- по умолчанию всегда Project Manager, так же как "филфак" по умолчанию филологический, а не филосовский.
Скажем, PMBOK -- про управление процессами, а не продуктом.
Забавно, что в это самое время в соседнем цехе празднуют победу объединения dev и ops как раз для избегания межличностного конфликта интересов.
Люблю это как пример провального перевода. Оригинальное название Dark Fields в данном контексте скорее переводится как "белые пятна" или как "неизведанные области".
Увы, такими темпами можно вообще отказаться от измерения чего-либо.
Это примерно как отказаться всех тестов и замеров производительности у отдельных компонентов сложной программной системы, в пользу исключительно e2e тестов и замеров всей системы в сборе. Правда в том, что нужно и то и другое для разных целей.
Для начала оговорим, что, судя по контексту, тут речь про рекрутеров (это лишь одна HR ролей). Они бывают штатные и внештатные. Возьмём для простоты внештатных и посмотрим на систему оплаты их труда. Общепринятая рыночная практика -- внештатный рекрутер получает деньги, если приведённый ими кандидат принял предложение о работе.
За всех остальных приведённых кандидатов внештатный рекрутер не получает ничего.
За дальнейшую судьбу сотрудника в компании внештатный рекрутер обычно не отвечает -- его задача привести кандидатов, а дальше уже ответственность перекладывается на нанимающих сотрудников компании.
Таким образом, видим, что внештатный рекрутер отвечает только за начальный этап воронки набора сотрудников. Первая наивная мысль -- раз платят за нанятых сотрудников (поштучно или взвешенно в зависимости от размера компенсации или уровня квалификации), то в интересах рекрутера навалить в эту воронку как можно больше кандидатов. Однако, такой подход по факту не работает: если внештатный рекрутер начинает приводить неподходящих кандидатов и, как следствие, конверсия кандидатов в сотрудники снижается, порожняком нагружая сотрудников компании собеседованиями, то компания перестанет сотрудничать с этим рекрутером. Похожая история может произойти и с кандидатами, которые тоже обычно не заинтересованы бесплодно собеседоваться на неподходящие роли.
Вот и видим, что у внештатного рекрутера появляются естественным образом две метрики эффективности -- число приведённых кандидатов и их конверсия.
И компания будет готова заплатить больше тому внештатному рекрутеру, который сможет показать лучшие метрики.
Вот такими метриками эффективности и разделяются границы составных частей системы. И важно из замерять -- это базовый принцип декомпозиции, активно применямый в науке для исследований и в управлении сложными системами.
Таким же образом можно замерять эффективность любой сколь-либо повторяемой и стандартизируемой работы. И мы знаем, что заметная часть разработчиков -- формошлёпы и CRUD-оделы, чья работа не подразумевает значительной исследовательской работы с большихм коэффециентом неопределённости.
vmware == вендорлок. Что, если завтра они поднимут цену в 10 раз или технологически свернут не туда? Или перестанут оказывать услуги для клиентов в определённой юрисдикции?
Я застал пеереезд в vwmare на openstack в одной большой и известной организации году так в 2012. Даже тогда, во времена господства vmware в области виртуализации, это был прямо прорыв.
Не совсем. Сбор аудитных логов есть отдельно от Event Notifications в AWS и GCP.
Суть Event Notifications в том, что на события в сервисе можно повесить свои кастомные обработчики. Например, запустить cloud serverless function / lambda.
Впрочем, допускаю, что эту же функциональность вполне можно самому реализовать на основе аудитных логов, которые придётся постоянно мониторить.
оригинал:
перевод:
Пожалуйста, прекратите, называть аутентификацию авторизацией. Если так не нравится слово "аутентификация", можно писать "страница входа в учётную запись".
Боюсь, тут наблюдается непонимание роли управляющего продуктом. Эта роль не подразумевает управление процессами разработки.
Хоть я и не Дмитрий, а иной чувак, отвечающий за инфраструктуру в другом стартапе, но могу рассказать на примере GCP. В GCP эту задачу решают аж три продукта: Apigee, Managed API Gateway и Managed Endpoints.
Предположим, мы хотим решать задачу монетизации API. То есть, чтобы не растаскивать специфическую логику по бекендам, API Gateway должен:
1) аутентифицировать пользователей, ходя в некоторую auth db с кешированием у себя
2) проверять статус оплаты -- некоторую метаинфу, взятую из биллинга
3) в зависимости от статуса -- возвращать на запросы ошибку или устраивать rate limiting (что тоже сводится к возврату ошибки в какой-то момент, вместо передачи запроса бекенду)
4) отправлять в биллинг статистику потребления в разбивке по пользователям в реальном времени
Apigee -- типичный кровавый энтерпрайз с развесистыми XML-конфигами и конскими ценами, купленный Google в 2015.
Он умеет делать перечисленное, но стоить это будет в минимальной конфирурации $30к в год (и оплата на год вперёд, договор и всё такое -- для стартапа прямо мечта) и всё равно придётся многое дописывать и допиливать. Да и не очень-то cloud-native решение, как ни странно -- IaaS для конфигурации всего это дело представлен почти незадокументированным плагином. Ни о чём вроде terraform провайдер мечтать не приходится.
Managed API Gateway -- чрезмерно минималистичный продукт, который только по сути маршрутизацию запросов по разным бекендам умеет делать и очень кривую аутентификацию на статичных API-ключах. Никаких возможностей интеграции с биллином и условной логики нет. Ах да, ещё конфигурируется это всё исключительно на Swagger 2, про OpenAPI 3 они не слышали и внедрять не планируют.
Managed Endpoints -- похожая сущность на Managed API Gateway, разве что в основе взят Extensible Service Proxy v2 -- сборка Envoy, конфигурируемая через GCP-сервис управления конфигами.
В общем, так я и не смог решить встроенными GCP инструментами описанную задачу.
Поэтому пришлось отправиться в OpenSource и external SaaS миры, где, увы, в этом месте всё тоже оставляет желать лучшего -- прямо чтобы парой кликов заработал интегрированный с API Gateway портал API разработчика, где можно привязать карту для оплаты и смотреть отчёты биллинга -- с этим 3.5 компании пытаются что-то делать и скорее в зачаточном состоянии.
Hiring manager. Нанимающий руководитель.
Ну да, чистое же совпадение, что в единственной стране, где у Google есть конкурент на открытом рынке, диалог выбора поисковой системы в chromium based браузерах показываться не должен.
https://bugs.chromium.org/p/chromium/issues/detail?id=81578
Ещё бы знать, что авторизация (от authority, буквально: уполномочивание) -- это и есть та самая "работа с пермишнами". А то, что в этой статье называется этим словом -- аутентификация (от authenticity, буквально: проверка подлинности).
И по этой же причине понятие "авторизоваться" (то есть, уполномочить себя) не имеет смысла.
И да, использование правильной терминологии -- важно и позволяет сэкономить время при обсуждении. По той причине, что нередко за эти две задачи отвечают разные независимые компоненты. И то, что проблемы с аутентификацией и авторизацией решаются разными способами.
Касательно "ВПО": напомню, чем "программа" отличается от ПО согласно ГОСТ 19781-90 и ISO/IEC 2382-1:1993 -- прилагаемой документацией. Они распространяли документацию? Если нет, то это "вредоносная программа", а не "ВПО".
А на чём написана самая большая в мире соцсеть? Много ли разницы?
Я активно использую GPU в контейнерах -- проблемы с этим нет, спасибо за это nvidia-container-runtime. Хотя с трудом представляю, зачем может пригодится GPU во время сборки -- разве что, для прогона тестов характерных.
И сборочные задачи (многие из которых довольно замысловатые) у меня все запускаются в контейнерах и пока ни потребности ни желания работать с хостовой не появлялось, потому и спрашиваю.
Можно пример случая, когда неудобно работать с CI задачей в докере?
"Власти подумали-подумали и пришли к компаниям с простым условием: либо 60% времени ваши сотрудники ходят в офис и тратят там деньги, либо хрен вам, а не налоговые льготы"
Можно источник?
Supervisor вообще потерял какой-либо смысл с момента распространения systemd
BGP работает на канальном уровне?
Если что, Satisfactory -- это готовый вариант "Factorio 3D"