Рубрика «процессы» - 4

Звонит как-то вендор и говорит, что в возврате бракованного железа — не их жёсткий диск.

Странные управленческие решения внутри хостинга - 1


Это местный вендор. Для прода мы покупаем серверное железо у крупных поставщиков, часто возим его в разные страны из одного центра. Но для тестовых новых конфигураций обращаемся к локальным поставщикам, берём железо на тесты или разовые проекты. Один из жёстких дисков оказался бракованным, и мы вернули его назад поставщику по гарантии. Причём знатно ругаясь, что связались с маленькой компанией, что задержало нам график тестов.

Гарантийный отдел ковыряется с диском, а потом звонят:

— А зачем вы подменили диск?

Мы такие:

— В смысле подменили?

— Мы вам продавали другой. А тут корпус тот, а внутри — другой. Какие-то следы от отвёртки.

Дичь полнейшая! Мы начали было ругаться, но потом стали разбираться. Начали смотреть на камеры и увидели, что наш сотрудник очень подозрительно себя вёл, когда работал с этим диском в стойке. Как в плохих комедиях про жуликов: постоянно осматривался по сторонам, отходил в сторону, возвращался. Оказалось, что он подменил диск. Честно, я не знаю зачем. Его финансовая выгода минимальная, скорее всего, даже не окупает время работы по замене корпуса.

У нас было ещё несколько странных ситуаций, и сейчас я о них расскажу. Читать полностью »

— Что вы думаете о глобальном потеплении?
Спросила с экрана гигантская морда хаски в черных солнечных очках.
— В каком смысле? Это уже интервью?
— Я прошу вас сфокусироваться. Как я только что сказала, сейчас я буду задавать вопросы на которые прошу вас давать максимально емкие ответы. Если у вас есть какие-то вопросы по процессу, пожалуйста я готова на них ответить. Нам нужно уложиться в отведенное время.
— Я просто не понял, что мы перешли к официальной части. У вас какие-то проблемы с камерой.
— Секунду.
На экране появилось лицо в сине-зеленой маске натянутой на уши с красным логотипом БК посередине.
— Согласно политике компании, все интервью мы проводим в масках. Мне подождать вас или мы не сможем продолжить?Читать полностью »

Когда я редактировала страницу о возможностях контейнеров для журнала «How Containers Work», мне потребовалось объяснить, почему в Docker не работает strace. Вот что случалось при запуске strace в Docker-контейнере на моем ноутбуке:

$ docker run  -it ubuntu:18.04 /bin/bash
$ # ... install strace ...
root@e27f594da870:/# strace ls
strace: ptrace(PTRACE_TRACEME, ...): Operation not permitted

strace работает через системный вызов ptrace, поэтому без разрешения для ptrace ничего не заработает! Но это легко исправить, и на моем ноутбуке я все сделала вот так:

docker run --cap-add=SYS_PTRACE  -it ubuntu:18.04 /bin/bash

Но мне было интересно не решить проблему, а разобраться, почему эта ситуация вообще возникает. Так почему же strace не работает, а --cap-add=SYS_PTRACE все исправляет?
Читать полностью »

TLDR: кому перестановки делают больнее — меряем свёрткой графов.
Код: RolX и ванильная трёхслойная GCN на мотифах.

Выгорание на рабочем месте повстречал ещё в начале своей карьеры — и с тех пор живо интересуюсь этим вопросом. Представьте обстановку. Большой проект внедрения SAP. Высокие ставки. Амбициозные сроки. Нагрузку каждый воспринимал по-своему. Кто-то сорвался и самоустранился от выполнения обязанностей, кто-то стал токсичнее, у меня самого в какой-то момент чувство юмора пропало. Ненадолго.

image

Управление изменениями (дисциплина, направленная на снижение напряжения во время внедрения информационных систем) многим обязана медикам. Во-первых, сам феномен эмоционального выгорания впервые зафиксировали у медицинских работников. Во-вторых, первое масштабное исследование, обобщающее 68 кейсов значительных перемен в английских госпиталях, открыло правила успеха для агентов изменения. Кроме того, моделирование эпидемий решает задачу максимизации влияния и позволяет внедрять нововведения быстрее и естественнее через (суб)оптимально выбранных людей на нужных местах.

Всё больше медучреждений перепрофилируют и это вызывает у работников ожидаемый стресс. Покажем, как его можно измерить, а уж где знаки препинания в заголовке ставить — решайте сами.Читать полностью »

В офисе никого: разработка игр на удаленке - 1

Дисклеймер. У нас нет «удаленных» сотрудников — в команде все равноудалены друг от друга. Просто кто-то работает (сейчас правильнее сказать «работал») в офисе, а кто-то дома или в коворкинге. Поэтому внутри мы предпочитаем термин «распределенная команда».

Переход на распределенную команду начался довольно давно. Сначала было страшно, но в итоге повысилась эффективность всех сотрудников, даже в офисе. Решили поделиться опытом и собрать развернутый материал по внутренним процессам.

У нас много команд занимающихся разработкой продуктов — есть и по 10 человек, и по 40-50 — но нет ни одной, где все ребята сидели бы рядом в офисе. Зато есть команды, которые полностью работают из дома. Из-за последних событий на «домашний режим» перешли вообще все, но пандемия практически не повлияла на процессы, потому что всё было выстроено заранее.

Дальше — несколько больших разделов о внутренней кухне: онбординг, коммуникации и работа с командой, обмен опытом. А для разнообразия разбавим текст фотографиями наших «домашних офисов». Читать полностью »

Кто такой DevOps и когда он не нужен - 1

Тема DevOps за последние несколько лет стала очень популярной. Некоторые мечтают в нее влиться, но, как показывает практика, часто только из-за уровня зарплат.

Многие указывают в своем резюме DevOps, хотя не всегда знают и понимают суть термина. Кто-то считает, что изучив Ansible, GitLab, Jenkins, Terraform и им подобные (список можно продолжать на свой вкус), то сразу станет «девопсом» с зарплатой 300к/нс. Это, конечно, не так.
Читать полностью »

Звездолеты на ДВС. Выжить в схватке с техническим долгом - 1

Как выжить в схватке с техническим долгом? Что делать, если у вас легаси тяжелой стадии? В статье на примере трёх кейсов предлагаю разобраться, как построить процесс работы с техническим долгом и какие инженерные подходы для этого использовать.
Читать полностью »

Всем привет! Меня зовут Александр Афенов, я тимлид команды Order Processing в компании Lamoda. Сегодня я хочу вам рассказать о практиках обмена знаниями: какие проблемы эти практики решают, как мы к ним пришли, и как они влияют на жизнь разработчика.

image

Читать полностью »

75%

3 из 4 — так Boston Consulting Group оценивает долю IT проектов, почивших по не-техническим причинам.

Уже вот две подряд редакции свода знаний по управлению проектами (PMBOK) выделяют процессы по управлению стейкхолдерами в отдельную область знаний под счастливым номером 13 и настоятельно рекомендуют учитывать:

1. связи между ними,
2. центры влияния, а также
3. культуру общения — для повышения шансов на успех.

Вопрос один:

 доколе инженеры о стейкхолдерах будут судить догадками?

image

ФОТО: Шариф Хамза для Dazed & Confuzed, модель — Люпита Нионго

В свете недавней безоговорочной победы русской математики над вопросом хроматических чисел рассмотрим сценарий применения стремительно набирающей популярность среди занимающихся машинным обучением теории графов к причине провала большинства IT проектов. Приложим вполне естественную науку о вычислениях к областям, ранее считавшимся 'мягкими'. И покажем, как современные модели позволяют организацию в эпоху перемен измерить. Стратегия решения — простая, двухшаговая — строим граф связей стейкхолдеров, а из него — нейросеть сворачиваем. И пока самообучаемые алгоритмы выполняют непростые управленческие задачи, снимая менеджерских проблем ворох с плеч человеческих — пьём кофе с пироженками.

Читать полностью »

Программист-защитник сильнее энтропии - 1

© Dragon Ball. Goku.

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

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

Давайте разберёмся подробнее, что входит в понятие «падать изящно».

  • Падать быстро. В случае непредвиденной ошибки все операции должны завершаться сразу же, особенно если последующие вычисления тяжёлые или могут привести к порче данных.
  • Падать аккуратно. Если возникла ошибка, программа должна освободить все ресурсы, снять локи, удалить временные и наполовину записанные файлы, закрыть соединения. Дождаться завершения критических операций, прерывание которых может привести к непредсказуемым результатам. Либо безопасным способом аварийно завершить эти операции.
  • Падать явно и красиво. Если что-то сломалось, сообщение об ошибке должно быть простым, лаконичным и содержать важные детали из того контекста системы, где возникла ошибка. Это поможет команде, которая отвечает за систему, максимально быстро разобраться в проблеме и исправить её.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js