Post #372
2.11K
Channel Public Channel
УЮ - Subscribers
- 3.57K
- Photos
- 89
- Videos
- 8
- Links
- 222
Showing posts older than #373 · Back to latest
Older Posts 20 shown
Post #371
1.89K
😌 Управление ожиданиями, кейс №1
У тебя есть две задачи А (30 часов) от Васи и Б (10 часов) от Екатерины на ближайший недельный спринт. К тебе приходит менеджер Виссарион и просит сделать задачу Д (20 часов). При этом ты точно знаешь, что Д — супер-срочная. Что будешь делать с задачами?
Условно считаем, что у нас реально есть 40 часов в неделю, встречи-оффтопики для простоты как бы включены в оценку времени.
Вы сами решаете кем быть — формалистом, карьеристом или полезным человеком, насколько зрелая ваша компания и т.п. Ответ формулируем с позиции исполнителя, а не руководителя команды.
Мой ответ с объяснением позиции — через несколько дней.
У тебя есть две задачи А (30 часов) от Васи и Б (10 часов) от Екатерины на ближайший недельный спринт. К тебе приходит менеджер Виссарион и просит сделать задачу Д (20 часов). При этом ты точно знаешь, что Д — супер-срочная. Что будешь делать с задачами?
Условно считаем, что у нас реально есть 40 часов в неделю, встречи-оффтопики для простоты как бы включены в оценку времени.
Вы сами решаете кем быть — формалистом, карьеристом или полезным человеком, насколько зрелая ваша компания и т.п. Ответ формулируем с позиции исполнителя, а не руководителя команды.
Мой ответ с объяснением позиции — через несколько дней.
Post #370
2.3K
Давайте будем документировать архитектурные решения!
Хороший лозунг, понятно из какой боли он произрастает. Сложно онбордить, сложно поддерживать, сложно дорабатывать, сложно рефакторить. Хочется общую картинку.
Я часто видел, как в результате команды приходили к идее сделать какой-то вид ADR (Architecture Decision Record) — фиксировать каждое архитектурное решение в виде этакой блогозаметки.
На мой взгляд это хорошее решение и это ужасное решение.
Хорошее — потому что это лучше чем ничего, и даже внедрение подобного подхода требует мощного волевого усилия. Вот, кстати хорошая статья с самым простым шаблоном: https://infraeng.dev/decision-log/
Плохое — потому что начиная записей с 30 разобраться в этом становится невозможно. Мне кажется, что тут лучше подход wiki: выделить абстрактные сущности (например, такие: https://youtu.be/NGiN3df_YGc?t=571) и с каждым решением — обновлять описания каждой из сущностей, затрагиваемых изменением (методы API, компоненты, фунциональные/не функциональные требования, бизнес-возможности пользователей и т.п.) и аккуратно пролинковывать зависимости.
Это сложнее, требует сурового онбординга для новичков, но гораздо прозрачнее в использовании. Причём изучение можно начать с того места, которое тебя волнует здесь и сейчас — меняя сущность ты от неё можешь размотать все взаимосвязи.
Хороший лозунг, понятно из какой боли он произрастает. Сложно онбордить, сложно поддерживать, сложно дорабатывать, сложно рефакторить. Хочется общую картинку.
Я часто видел, как в результате команды приходили к идее сделать какой-то вид ADR (Architecture Decision Record) — фиксировать каждое архитектурное решение в виде этакой блогозаметки.
На мой взгляд это хорошее решение и это ужасное решение.
Хорошее — потому что это лучше чем ничего, и даже внедрение подобного подхода требует мощного волевого усилия. Вот, кстати хорошая статья с самым простым шаблоном: https://infraeng.dev/decision-log/
Плохое — потому что начиная записей с 30 разобраться в этом становится невозможно. Мне кажется, что тут лучше подход wiki: выделить абстрактные сущности (например, такие: https://youtu.be/NGiN3df_YGc?t=571) и с каждым решением — обновлять описания каждой из сущностей, затрагиваемых изменением (методы API, компоненты, фунциональные/не функциональные требования, бизнес-возможности пользователей и т.п.) и аккуратно пролинковывать зависимости.
Это сложнее, требует сурового онбординга для новичков, но гораздо прозрачнее в использовании. Причём изучение можно начать с того места, которое тебя волнует здесь и сейчас — меняя сущность ты от неё можешь размотать все взаимосвязи.
- 👍 14
Post #369
1.79K
Forwarded from Cross Join - канал о разработке (Anton Okolelov)
Javascript почему-то игнорирует дефолтный порт, даже если он был явно указан.
Счастливой отладки :)
Счастливой отладки :)
- 🔥 6
- 🤔 4
- 🤯 3
Post #368
2.34K
Давным-давно работал я в компании, занимавшейся заказной разработкой. Будем откровенны, для заказной разработки один из важных моментов — разделение ответственности и быстрое решение конфликтов. Потому что никому не хочется разбираться с множеством исправлений за свой счёт. Плюсом к этому в компании не хватало внутренних коммуникаций: договорённости фиксировались плохо, а словам верить было не принято.
И созрел план — наладить коммуникацию через написание архитектурной документации, фиксировать в ней договорённости, возникающие между разными ветвями разработки и менеджментом. Разработали шаблоны, чтобы было проще фиксировать мысли. Обучили разработчиков новому и встроили практики в рабочий процесс. На мой сегодняшний вкус — возможно чрезмерно жёстко, по принципу "нет архитектурного описания — нет задачи", но это работало.
Ну… Как работало… )
Первые полгода-год меня поносили всеми немыслимыми словами и менеджеры, и разработчики. Добавил работы на пустом месте.
А потом люди начали понимать плюсы, особенно когда проект зарелизили и полезли баги в production. Когда благодаря зафиксированным знаниям разработчикам удавалось быстро влезать в незнакомые сервисы, а менеджеры сами могли диагностировать проблемы с помощью Postman и хорошего описания API.
Некоторые изменения очень трудно продать, невозможно забыть и очень непросто оценить. Но таков путь.
И созрел план — наладить коммуникацию через написание архитектурной документации, фиксировать в ней договорённости, возникающие между разными ветвями разработки и менеджментом. Разработали шаблоны, чтобы было проще фиксировать мысли. Обучили разработчиков новому и встроили практики в рабочий процесс. На мой сегодняшний вкус — возможно чрезмерно жёстко, по принципу "нет архитектурного описания — нет задачи", но это работало.
Ну… Как работало… )
Первые полгода-год меня поносили всеми немыслимыми словами и менеджеры, и разработчики. Добавил работы на пустом месте.
А потом люди начали понимать плюсы, особенно когда проект зарелизили и полезли баги в production. Когда благодаря зафиксированным знаниям разработчикам удавалось быстро влезать в незнакомые сервисы, а менеджеры сами могли диагностировать проблемы с помощью Postman и хорошего описания API.
Некоторые изменения очень трудно продать, невозможно забыть и очень непросто оценить. Но таков путь.
- 👍 37
- 🔥 16
Post #367
1.83K
- 🤔 3
Post #366
1.99K
Почему не пишется лог?
Подумайте над этим пару минут, какие могут быть варианты. Ну или напишите в комментарии — порассуждаем вместе!
А потом посмотрите увлекательный ответ под спойлером ниже ⬇️
Потому что стектрейс настолько большой, что либа логгирования падает.
Подумайте над этим пару минут, какие могут быть варианты. Ну или напишите в комментарии — порассуждаем вместе!
А потом посмотрите увлекательный ответ под спойлером ниже ⬇️
Потому что стектрейс настолько большой, что либа логгирования падает.
- 🤯 17
Post #365
2.06K
Модерация сообществ
https://vas3k.blog/notes/moderation/
vas3k сделал отличный лонгрид про подводные камни модерации сообществ и влияния оной модерации на жизнь онлайн-коммьюнити. Многое говорит о проблемах формулировки командных правил вообще.
Особенно рекомендовано читать людям от мира управления знаниями, мечтающим сделать платформу, и чтобы оно дальше как-то само происходило и люди сами делились знаниями.
https://vas3k.blog/notes/moderation/
vas3k сделал отличный лонгрид про подводные камни модерации сообществ и влияния оной модерации на жизнь онлайн-коммьюнити. Многое говорит о проблемах формулировки командных правил вообще.
Особенно рекомендовано читать людям от мира управления знаниями, мечтающим сделать платформу, и чтобы оно дальше как-то само происходило и люди сами делились знаниями.
- 🔥 8
- 👍 1
Post #364
1.84K
👀 невербалики пост
Поговорим об информации, получаемой не через слова, но через невербальные сигналы. От 60 до 70 процентов информации мы получаем через зрение: мимика, жесты, позы, движения глаз, интонации голоса, ассоциации и тональность голоса. Всё это влияет на понимание собеседника.
Однако, мозг не всегда умеет анализировать все эти сигналы и связывать их со смыслом слов, произносимых собеседником. Иногда нас могут клинить какие-то незначительные детали, например, тональность голоса или интонация. Всё это влияет на наше восприятие и оценку происходящего.
И поскольку это — интерпретации, они могут быть искажены нашими предрассудками, настроением или даже здоровьем.
Поэтому для себя я выработал два правила:
1. не было сказано — значит не было
2. чувствуете, что что-то не так — лучше взять небольшой перерыв, сформулировать невербальные сигналы словами и спросить у собеседника, правильно ли вы понимаете его реакцию или поведение.
Иногда простое вопрос "правильно ли я понимаю, что вы сейчас проявляете агрессию ко мне?" может решить очень много вопросов и предотвратить конфликты. Не бойтесь обращаться за уточнением, ведь правильное восприятие и понимание друг друга - это залог успешного общения и взаимодействия.
Поговорим об информации, получаемой не через слова, но через невербальные сигналы. От 60 до 70 процентов информации мы получаем через зрение: мимика, жесты, позы, движения глаз, интонации голоса, ассоциации и тональность голоса. Всё это влияет на понимание собеседника.
Однако, мозг не всегда умеет анализировать все эти сигналы и связывать их со смыслом слов, произносимых собеседником. Иногда нас могут клинить какие-то незначительные детали, например, тональность голоса или интонация. Всё это влияет на наше восприятие и оценку происходящего.
И поскольку это — интерпретации, они могут быть искажены нашими предрассудками, настроением или даже здоровьем.
Поэтому для себя я выработал два правила:
1. не было сказано — значит не было
2. чувствуете, что что-то не так — лучше взять небольшой перерыв, сформулировать невербальные сигналы словами и спросить у собеседника, правильно ли вы понимаете его реакцию или поведение.
Иногда простое вопрос "правильно ли я понимаю, что вы сейчас проявляете агрессию ко мне?" может решить очень много вопросов и предотвратить конфликты. Не бойтесь обращаться за уточнением, ведь правильное восприятие и понимание друг друга - это залог успешного общения и взаимодействия.
- 👍 10
Post #363
1.8K
🤬 МЫ НЕ РЕЛИЗИМСЯ В ПЯТНИЦУ!!!!
Правило не релизиться в пятницу — это суеверие.
Я убеждён, у сломанных релизов есть объективные причины: плохое тестирование, неучёт рисков, отсутствие плана отката, отсутствие мониторинга, отсутствие нужных людей поблизости, чудовищный техдолг, сбой во внешнем софте или оборудовании.
Мне оппонируют — “Игорь, ты о каких-то космических штуках пишешь, у нас люди говнокод пишут и задачи не успевают закрывать, нам некогда!”. Поэтому, мол, будем писать как можем, а в пятницу релизить — нельзя.
Тем не менее:
Если релизы систематически ломаются и люди закрывают проблемы переработками, то “не релизиться в пятницу” — это не решение, это манипуляция-суеверие, чтобы защититься от бесконтрольных овертаймов.
Закрывшись этим лозунгом вы никак не движетесь к улучшению ситуации.
Релизясь в пятницу, ускоряя развитие продукта, улучшая инфраструктуру по итогам каждой аварии — движетесь. Но только если ваши менеджеры — не мудаки и правильно задают вектор движения команды.
Есть ситуации, в которых релизы в пятницу сомнительны, но они не связаны со страхом потерять выходные, например:
- в пятницу/выходные сложно достучаться до людей, необходимых для решения инцидентов (админы на подряде не работают по выходным; менеджер в выходные на рыбалке и плевал на всё)
- в пятницу/выходные — повышенный трафик и авария принесёт огромные потери (у многих бизнесов есть сезонность: праздники, новый год, 1 сентября, 8 марта и т.п.)
Если же изменение не протестировано, не готово, плана отката нет, но мы всё равно катим его на прод, потому что “надо” — будет больно что в выходные, что в будни, и дело в болевом пороге, а не в замедляющем развитие суеверии.
Правило не релизиться в пятницу — это суеверие.
Я убеждён, у сломанных релизов есть объективные причины: плохое тестирование, неучёт рисков, отсутствие плана отката, отсутствие мониторинга, отсутствие нужных людей поблизости, чудовищный техдолг, сбой во внешнем софте или оборудовании.
Мне оппонируют — “Игорь, ты о каких-то космических штуках пишешь, у нас люди говнокод пишут и задачи не успевают закрывать, нам некогда!”. Поэтому, мол, будем писать как можем, а в пятницу релизить — нельзя.
Тем не менее:
Если релизы систематически ломаются и люди закрывают проблемы переработками, то “не релизиться в пятницу” — это не решение, это манипуляция-суеверие, чтобы защититься от бесконтрольных овертаймов.
Закрывшись этим лозунгом вы никак не движетесь к улучшению ситуации.
Релизясь в пятницу, ускоряя развитие продукта, улучшая инфраструктуру по итогам каждой аварии — движетесь. Но только если ваши менеджеры — не мудаки и правильно задают вектор движения команды.
Есть ситуации, в которых релизы в пятницу сомнительны, но они не связаны со страхом потерять выходные, например:
- в пятницу/выходные сложно достучаться до людей, необходимых для решения инцидентов (админы на подряде не работают по выходным; менеджер в выходные на рыбалке и плевал на всё)
- в пятницу/выходные — повышенный трафик и авария принесёт огромные потери (у многих бизнесов есть сезонность: праздники, новый год, 1 сентября, 8 марта и т.п.)
Если же изменение не протестировано, не готово, плана отката нет, но мы всё равно катим его на прод, потому что “надо” — будет больно что в выходные, что в будни, и дело в болевом пороге, а не в замедляющем развитие суеверии.
- 🔥 16
- 👍 7
- 💩 2
- 🤔 1
Post #362
1.52K
Post #361
1.54K
Качество импортозамещающего софта должно измеряться в количестве разочарованных "ну бляяяяя!!!..." в день.
Наболело.
Наболело.
- 👍 28
- 🎉 4
- 🤔 1
Post #360
5.29K
Корпоративный поиск на коленке
Люблю тему поиска, особенно в контексте управления знаниями. Посвятил ей пару-тройку лет.
А вот и опубликовали мой рассказ о том, как на коленке построить свой корпоративный поиск и как это сделать с минимумом возможной боли:
https://www.youtube.com/watch?v=q9TMFdRFK2Q
С развитием LLM и ChatGPT, с одной стороны, ситуация изменилась, а с другой — если нам важна точность в ответах — не особо 🙂 Так что интересующимся концептуальной стороной вопроса построения поиска, думаю, будет интересно. Старался отразить основы, которые вряд ли будут меняться.
Видео писалось во время болезни, прошу понять и простить заминки и прокашливания.
YouTube Мастер-класс "Корпоративный поиск на коленке с помощью opensource-решений и Elasticsearch" Игорь рассказывает о том, как "под капотом" устроен поиск, и корпоративный поиск в частности, в на мастер-классе рассмотрены:
1. Проблема множества информационных систем и источников данных.
2. Проблема того, каково при большом IT-ландшафте делиться своими… Люблю тему поиска, особенно в контексте управления знаниями. Посвятил ей пару-тройку лет.
А вот и опубликовали мой рассказ о том, как на коленке построить свой корпоративный поиск и как это сделать с минимумом возможной боли:
https://www.youtube.com/watch?v=q9TMFdRFK2Q
С развитием LLM и ChatGPT, с одной стороны, ситуация изменилась, а с другой — если нам важна точность в ответах — не особо 🙂 Так что интересующимся концептуальной стороной вопроса построения поиска, думаю, будет интересно. Старался отразить основы, которые вряд ли будут меняться.
Видео писалось во время болезни, прошу понять и простить заминки и прокашливания.
- 🔥 7
- 👍 1
- 💩 1
Post #359
2.05K
KnowledgeConf — про управление знаниями
Следующая конференция будет этой осенью, 30 ноября и 1 декабря, на одной площадке с TeamLead Conf и TechLead Conf. На мой взгляд — бомбическое сочетание технологий, процессов и людей!
Уже открыт приём заявок на доклады: https://cfp.knowledgeconf.ru/ — на странице всё подробно прописано и про условия, и про аудиторию, и про темы.
А для тех, кто не знает о чём конкретно рассказать / не уверен буквально через час (в 17:00 Мск) будет встреча с ПК. Записаться и получить ссылку можно тут: https://conf.ontico.ru/event/join/open_kc2023.html
Следующая конференция будет этой осенью, 30 ноября и 1 декабря, на одной площадке с TeamLead Conf и TechLead Conf. На мой взгляд — бомбическое сочетание технологий, процессов и людей!
Уже открыт приём заявок на доклады: https://cfp.knowledgeconf.ru/ — на странице всё подробно прописано и про условия, и про аудиторию, и про темы.
А для тех, кто не знает о чём конкретно рассказать / не уверен буквально через час (в 17:00 Мск) будет встреча с ПК. Записаться и получить ссылку можно тут: https://conf.ontico.ru/event/join/open_kc2023.html
- 👍 2
- 🎉 2
- 💩 2
Post #357
2.05K
Иногда натыкаюсь на руководителей (технических и не очень), которые дают охуенные, блять, советы. Убогие как по форме, так и по содержанию. Как-то по итогам инцидента:
- я бы получше продумал архитектуру, уточнил бы всё что надо, и уделил бы внимание безопасности
- можно провести анализ узких мест и провести тестирование, чтобы обнаружить баг
- может быть стоит прогнать тесты, это могут быть разные проблемы, и возможно в процессе анализа станет понятнее
Почему меня бомбит? Потому что эти советы пустые. Экспертиза Тони Роббинса, делайте хорошо, не делайте плохо.
Утекли данные — значит надо уделить внимание безопасности. Большое потребление ресурсов — надо искать, куда они уходят. Для нахождения бага действительно нужно его локализовать.
Берёшь на себя ответственность — говори конкретно когда и что ты сделаешь.
Помогаешь своими знаниями — сужай поле поисков, уменьшай объём предстоящей коллегам работы.
Не готов вникать, не разбирался в проблематике — молчи, сука, в тряпочку! Тебе не платят за количество произнесённых слов.
Принимай решения. Бери ответственность.
Если даже руководители не могут дать конкретные и полезные советы, то как мне верить в то, что я работаю в команде профессионалов?
- я бы получше продумал архитектуру, уточнил бы всё что надо, и уделил бы внимание безопасности
- можно провести анализ узких мест и провести тестирование, чтобы обнаружить баг
- может быть стоит прогнать тесты, это могут быть разные проблемы, и возможно в процессе анализа станет понятнее
Почему меня бомбит? Потому что эти советы пустые. Экспертиза Тони Роббинса, делайте хорошо, не делайте плохо.
Утекли данные — значит надо уделить внимание безопасности. Большое потребление ресурсов — надо искать, куда они уходят. Для нахождения бага действительно нужно его локализовать.
Берёшь на себя ответственность — говори конкретно когда и что ты сделаешь.
Помогаешь своими знаниями — сужай поле поисков, уменьшай объём предстоящей коллегам работы.
Не готов вникать, не разбирался в проблематике — молчи, сука, в тряпочку! Тебе не платят за количество произнесённых слов.
Принимай решения. Бери ответственность.
Если даже руководители не могут дать конкретные и полезные советы, то как мне верить в то, что я работаю в команде профессионалов?
- 🔥 41
- 👍 7
- 💩 3
Post #356
2.04K
И молвит мне один товарищ: “Мы не будем описывать процессы! У нас гибкая компания, и вообще если процессы можно описать - то работу будут делать роботы, а у нас должны быть ЛЮДИ и люди должны думать!!!”
Вы сталкивались с компаниями, где процессы не описаны, задачи решаются “по ситуации” и наблюдается некоторый хаос и неэффективность? Вот что движет такими руководителями?
Отношение к людям как к спецам, которые сами вольны выкручиваться — одобряю. Взаимодействие важнее регламентов.
Но относится к регламентам как к скрипту — это какая-то нездоровая фигня от травмированного человека. Роботы не заменят людей, которые могут думать и принимать творческие решения.
Нет смысла отказываться от регламентов — они важны для поддержания прозрачности, порядка и эффективности. Они могут иметь формат чек-листов, шаблонов, подсказок, напоминалок, сформулированных ожиданий или схем — не в формате ограничения, а в формате поддержки.
А те, кто не хотят поддерживать коллег просто неуместны в командной работе.
Вы сталкивались с компаниями, где процессы не описаны, задачи решаются “по ситуации” и наблюдается некоторый хаос и неэффективность? Вот что движет такими руководителями?
Отношение к людям как к спецам, которые сами вольны выкручиваться — одобряю. Взаимодействие важнее регламентов.
Но относится к регламентам как к скрипту — это какая-то нездоровая фигня от травмированного человека. Роботы не заменят людей, которые могут думать и принимать творческие решения.
Нет смысла отказываться от регламентов — они важны для поддержания прозрачности, порядка и эффективности. Они могут иметь формат чек-листов, шаблонов, подсказок, напоминалок, сформулированных ожиданий или схем — не в формате ограничения, а в формате поддержки.
А те, кто не хотят поддерживать коллег просто неуместны в командной работе.
- 👍 23
- 🔥 8
Post #355
2.11K
Кому это нужно?
Когда сопровождаешь организационное изменение — важно осознавать кто из задействованных людей какие требования к результату предъявляет. А в идеале — ещё и понимать, чего каждый из них на самом деле хочет.
Собрать требования — тривиально, про это много сказано и написано. Интервьюирование, помощь людям в формулировке мыслей, разруливание конфликтов интересов почти ничем не отличается от аналогичных задач при разработке софта. Но есть и нюансы, о них и поговорим.
Важно не упустить момент, когда список задействованных людей внезапно расширяется или изменяется.
Например, внедряем в компании Рога и Копыта Scrum. Все вроде понимают зачем, но Вениамин, руководитель админов, начинает сопротивляться, мол:
- стендапы — это пустая потеря времени и отвлечение от работы
- самоорганизация — зло, нужна чёткая иерархия и контроль за принятием решений
- и вообще из-за вашего скрама сроки будут срываться — это вообще всем очевидно.
Обсуждение этих возражений с Вениамином “на ходу” не приводит ни к чему — след за одними возражениями возникают другие.
Вениамин отвечал за безопасность в гос. проектах и ему совсем не улыбалось подставлять себя и компанию написанным на коленке говнокодом. А нормально поговорить с ним о его требованиях — забыли, просто подключили “на ходу” добавив в рассылку уже во время реализации перехода на Scrum.
Для всех задач по организационным изменениям я в явном виде фиксируйте заинтересованных людей (в отдельном поле в трекере задач, например). Это поможет понять, не потерялся ли чей-то интерес, вовремя подумать о мотивах и требованиях участников процесса.
Когда сопровождаешь организационное изменение — важно осознавать кто из задействованных людей какие требования к результату предъявляет. А в идеале — ещё и понимать, чего каждый из них на самом деле хочет.
Собрать требования — тривиально, про это много сказано и написано. Интервьюирование, помощь людям в формулировке мыслей, разруливание конфликтов интересов почти ничем не отличается от аналогичных задач при разработке софта. Но есть и нюансы, о них и поговорим.
Важно не упустить момент, когда список задействованных людей внезапно расширяется или изменяется.
Например, внедряем в компании Рога и Копыта Scrum. Все вроде понимают зачем, но Вениамин, руководитель админов, начинает сопротивляться, мол:
- стендапы — это пустая потеря времени и отвлечение от работы
- самоорганизация — зло, нужна чёткая иерархия и контроль за принятием решений
- и вообще из-за вашего скрама сроки будут срываться — это вообще всем очевидно.
Обсуждение этих возражений с Вениамином “на ходу” не приводит ни к чему — след за одними возражениями возникают другие.
Вениамин отвечал за безопасность в гос. проектах и ему совсем не улыбалось подставлять себя и компанию написанным на коленке говнокодом. А нормально поговорить с ним о его требованиях — забыли, просто подключили “на ходу” добавив в рассылку уже во время реализации перехода на Scrum.
Для всех задач по организационным изменениям я в явном виде фиксируйте заинтересованных людей (в отдельном поле в трекере задач, например). Это поможет понять, не потерялся ли чей-то интерес, вовремя подумать о мотивах и требованиях участников процесса.
- 🔥 10
Post #354
3.21K
При расследовании инцидентов в достаточно крупной экосистеме зачастую начинаются поиски сбоящего компонента. Один из способов это сделать — смотреть на HTTP-коды и двигаться по направлению к источнику. Получил 502 на фронте — ищешь кто вернул 502 ему, и так далее, до причины.
И это помогает и работает, пока мы не сталкиваемся с восхитительным кодом 499.
Гугл говорит нам, что смысл этой ошибки — client closed request. То есть она указывает, что наше приложение такое выполняло свою логику, готовило-готовило ответ, но при попытке отправить очередную порцию ответа получателю обнаружило, что тот уже закрыл соединение, отправлять некуда.
Неочевидная же мысль, следующая из этого — корневую причину нужно искать не глубже по цепочке вызовов, а ближе в “поверхности”, в получателе, разорвавшем соединение. Или в его получателе. И так вплоть до клиентского приложения.
Очень может быть причина — в каком-то timeout/keepalive-параметре или более крупный косяк (например, пришедший OOM). Если пофиксить проблему в клиенте — ошибки уйдут.
И это помогает и работает, пока мы не сталкиваемся с восхитительным кодом 499.
Гугл говорит нам, что смысл этой ошибки — client closed request. То есть она указывает, что наше приложение такое выполняло свою логику, готовило-готовило ответ, но при попытке отправить очередную порцию ответа получателю обнаружило, что тот уже закрыл соединение, отправлять некуда.
Неочевидная же мысль, следующая из этого — корневую причину нужно искать не глубже по цепочке вызовов, а ближе в “поверхности”, в получателе, разорвавшем соединение. Или в его получателе. И так вплоть до клиентского приложения.
Очень может быть причина — в каком-то timeout/keepalive-параметре или более крупный косяк (например, пришедший OOM). Если пофиксить проблему в клиенте — ошибки уйдут.
- 👍 9
- 🔥 5
- 💩 1
Post #353
2.13K
Если в пятницу вечером вам хочется слать проклятья текущему месту работы — возможно у меня есть для вас возможность.
Один из лучших руководителей, с кем мне доводилось работать, мудрый и рассудительный @TheActiser, собирает команду в проект с внятными перспективами. Это неиллюзорная возможность сделать по-нормальному, как надо.
Подробности и часть вакансий тут: @svacancy
Сейчас они ищут Go, Python, React разработчиков, продактов, devops-ов, DBA, SRE, тестеров.
Есть поверье, что Николай в фигню не вписывается 🙂 Я глубоко признателен ему за годы нашей совместной работы, настолько, что нарушил правило отсутствия рекламы на канале.
Один из лучших руководителей, с кем мне доводилось работать, мудрый и рассудительный @TheActiser, собирает команду в проект с внятными перспективами. Это неиллюзорная возможность сделать по-нормальному, как надо.
Подробности и часть вакансий тут: @svacancy
Сейчас они ищут Go, Python, React разработчиков, продактов, devops-ов, DBA, SRE, тестеров.
Есть поверье, что Николай в фигню не вписывается 🙂 Я глубоко признателен ему за годы нашей совместной работы, настолько, что нарушил правило отсутствия рекламы на канале.
- 👍 11
- 🔥 5
Post #352
2.03K
Кандидаты начинают использовать chatgpt для ответов на вопросы — что делать?
А давайте спросим об этом ChatGPT!
Т.е. Цепочки вопросов вида "расскажите о своём прошлом опыте" -> "как вы использовали упомянутую технологию Х" -> "В контексте вашей ситуации почему вы сделали Y" не решаемы читером, диалог всё ещё является надёжным способом интревьюирования.
А давайте спросим об этом ChatGPT!
ChatGPT, даже обновленный до GPT-4, может преуспеть в отвечании на многие вопросы, но у него есть несколько ограничений, которые можно использовать для его определения.
- Вопросы про актуальные события: Поскольку обучение модели было завершено в сентябре 2021 года, она не знает о событиях, произошедших после этой даты. Если вы зададите вопрос о недавнем событии, человек сможет ответить на него, а AI - нет.
- Вопросы о субъективных чувствах или персональном опыте: GPT-4 не имеет собственных чувств или персонального опыта, и не может делиться реальными личными историями. Вопросы о персональном опыте могут помочь выявить использование AI.
- Вопросы, требующие продолжительного взаимодействия: GPT-4 не имеет способности помнить или отслеживать долгосрочные беседы. Если вы зададите вопросы, которые требуют последовательного ответа на ряд вопросов, AI может потерять контекст.
- Специфические вопросы, требующие особой экспертизы: GPT-4 имеет широкий, но поверхностный набор знаний. Если вопросы слишком специфические или требуют глубокой экспертизы, AI может дать неточный или упрощенный ответ.
Т.е. Цепочки вопросов вида "расскажите о своём прошлом опыте" -> "как вы использовали упомянутую технологию Х" -> "В контексте вашей ситуации почему вы сделали Y" не решаемы читером, диалог всё ещё является надёжным способом интревьюирования.