Байки про суровое российское ИТ и жертв цифровизации



    Россия иррациональна. Есть правильные практики, есть сто раз ощупанные грабли, но всё равно с завидным постоянством случается что-то эпическое. Иногда по причине: «Ну уж меня-то точно пронесёт», иногда: «Всегда так делали, и работало», иногда просто из-за ошибок. Возможно, в генах.

    Первый яркий пример невероятной дичи (детали немного изменены по требованию безопасников). Заказчик занимается капитальным строительством. Заказал несколько лет назад у подрядчика систему, которая управляет всем этим (в частности, сметными работами). Система была установлена на десятке немаленьких объектов, внедрена. Внезапно заказчик решил потребовать выдать ему исходный код. Как оказалось, у их имеющегося подрядчика были планы на то, что они проведут разработку софта, а потом будут продавать результат как SaaS по рынку. В договоре про код ничего не сказано. Поругались.

    Когда позвали нас разбираться, там было примерно 10 разных версий ПО (релизы от 0.9 до 2.4). Есть исходники 1.5, эта версия собиралась когда-то из них. Документации нет. А систему надо дорабатывать и развивать. Посчитали «переписать всё заново» и «доработать 1.5» и остановились на втором — TtM три-четыре месяца против года. Научили собирать спецов поддержки, поправили исходники, свели кодовые базы, сделали инфраструктуру, организовали одну «разливочную», куда принимается исходник, там собирается и дистрибутируется. Это стоило нам и заказчику большого количества геморроя.

    Заходите, покажу ещё примерно то, как можно поошибаться с процессом разработки, и к каким интересным последствиям это приводит.

    Ещё пример


    Заказчик — тоже немаленькая компания — накатывает релизы ERP. А прикол в том, что система такая здоровая, что на полной базе или чём-то похожем её тестировать негде. Просто нет инфраструктуры. Точнее, есть, но нельзя сделать нагрузочный тест, только мелкие локальные вещи проверяются. Релиз встаёт — и никто не знает, как он себя поведёт на деле. Один раз всё знатно так упало, когда релиз повёл себя не так, как хотелось. В итоге позвали нас смотреть, что можно сделать. Мы обсудили, что они хотят посмотреть HP Perfomance Center, сделали пилот, потом интегрировали, обучили, поставили. Теперь релизы — через него. Эти нормированные операции тестируются, сводная аналитика по SLA по операциям.

    Или вот у госзаказчика наступило импортозамещение. Бизнес приходит к нам и говорит: нам наши айтишники сказали, что заменить базу Оракл на Постгресс очень сложно. Мы им не верим, проконсультируйте. Две недели разбирательств — и результат: «Ну да, поменять базу несложно. Просто потом весь прикладной уровень придётся переписать. Немного. Примерно на 90%. У вас огромные пакеты, нужно переносить слой бизнес-логики — и приехали. Разработчиков, которые писали ядро, уже не найти, потому что системе восемь лет». Поверили ИТ-команде. Оказалось, просто недостаточно понятно аргументировали.

    Где-то безопасность смотрим, вот эпический пример. К счастью, этот ещё простой, там просто никто ничего пять лет не делал, и бизнес не федерального масштаба всё же.

    Следующий пример. Ставим ту же историю с приёмкой релизов. Идеальная ситуация: сторонний подрядчик пишет код, передаёт его на тестирование, проходит тесты, кладётся всё это в репозиторий, оттуда собирается и дистрибутируется. Красиво? Красиво. Мы так внутри своей компании уже года три живём без исключений (до этого были не все отделы и команды). А вот у заказчика — «фонд алгоритмов и программ». Туда каждый исполнитель отгружает болванку или распечатку исходного кода. Они там тлеют. Как оказалось в процессе аудита, на одну болванку вообще аниме записано. И даже если де-факто код в фонде есть, то толку нет.

    Другой похожий заказчик. У них типовая боль — много подрядчиков. Они сделали внутриотраслевого интегратора, они проверяют, что подрядчик приносит корректный софт. Там проблемы были в том, что есть права третьих лиц (библиотеки опенсорса с вирусными открытыми лицензиями, например) — нечистоплотные подрядчики могут поставить всё это без лицензирования по порядку. В случае опенсорса ещё можно как-то заныкать проблему, но иногда попадаются и коммерческие библиотеки. Виноват кто будет — угадайте с трёх раз. Потом один их подрядчик ещё и обанкротился, а заказчику с этим кодом жить. Такие ситуации надо ловить на ранней стадии. Мы помогли настроить процесс правильно. У нас есть решение типа автоматизации фонда алгоритмов и программ. Техническая документация, версии, исходники, договоры и все ссылки на тендеры. При среднем сроке жизни ИТ-директора два-три года это очень помогает следующему разбираться сразу.

    Ещё у нас в России внедряют аджайл. Я теперь в цирке не смеюсь. Почти каждый раз это начинается как модная история по цифровизации бизнеса. Главное, все пытаются понять, что это за слова. Но никто не понимает. Концепции заказывают, нанимают странных людей. Они говорят слова «кажется», «гипотеза», стартаперов приглашают, акселерацию мутят, смузи пьют — в общем, это всё имеет внешние признаки какой-то долины. Потом аджайл начинают применять, а он не взлетает. Если делаешь серьёзную систему, надо её долго проверять. Если не поставить процессы, то спринты будут долгие (месяц-два), если ставить процессы, то нужно начинать с инфраструктуры тестирования, девопса, делать конвейер поставки, процессы работы между командами и внутри команд. А это всё обычно забывают. Если процессы старообрядческие — 98%, что проект не будет сделан. В итоге потом нам разгребать и запускать. В целом мы не жалуемся: тоже хлеб. Но иногда просто хочется как-то объяснить, что ли, что ИТ — это сначала инфраструктура, а потом уже — быстрый TtM. А не наоборот.

    Что обычно идёт не так? Набор примеров


    Мы с коллегами собрали вот такой не очень объективный, но очень хорошо описывающий ситуацию набор ярких проблем. Понятное дело, мы ездим только туда, где плохо, и экстраполировать это на состояние отрасли не надо. Но всё же, уверен, вы узнаете что-то и от своей компании. Небольшую часть. В целом всё описывается словами: «неэффективность процессов, немотивированные сотрудники, плохие инструменты или плохо используемые инструменты». Ну а теперь — примеры.

    1. Штраф за ошибки в ПО, внесённом разработчиками.

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

    2. Собрания с утра до вечера.

    Разработчик должен на них присутствовать. Он молчит и кивает головой в трубку. Это те самые встречи, когда на совещании нужна вся проектная команда и плюс руководитель отдела, чтобы контролировать. Нельзя не прийти. Но смысла от участия почти нет. Это традиционная ошибка руководителя проекта, называется «избыточный контроль».

    3. Карго-культ. Берём гибкие методологии и жёстко их внедряем.

    Лучшее, что я видел: внедрили аджайл, но работали, как раньше. Только заставили разработчиков приходить на ежедневный стендап. Они строятся и рассказывают: я ничего не сделал. Это происходит изо дня в день.

    4. Инструменты: внедряем, чтобы отчитаться, что внедрены.

    «У нас есть Continious Integration-сервер, а задачу может добавить только администратор». «У нас внедрили хранилище бинарных сборок, а там очень маленький диск, надо удалять старые, и там только последние три версии». Или вот: система ведения задач в эксель-файле на пошареном диске. Так бэклог часто ведут даже в больших компаниях, при том, что есть и Jira. При этом пока задача не попадёт в этот файл, никто делать не будет. Он официальный.

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

    5. Стандарты кодирования: написаны без понимания или не обновлялись 10 лет.

    Просто пара примеров: требуем 100% покрытия кода тестами и документацией. В частности, всех сторонних библиотек. Обратная сторона — отсутствие стандартных тестов. Недавно видел, как инженер развернул систему, а пользователь не может войти, потому что ключ с теста на прод не поменяли.

    Ещё один раз видел, как руководитель писал код в Notepad.exe, потом кидал в компилятор без ошибок. Он с перфокарт ещё учился. Такой навык, конечно, заслуживает уважения. Но только до тех пор, пока эта профдеформация не начинает влиять на стандарты для остального отдела разработки.

    6. Ошибки регламента.

    Например, фиксированное время обеда, которое выгуливается полностью. Это симптом. Спрашиваю, почему. Объясняют: если ты на рабочем месте сидишь в обед, то ты мишень. Должен отвечать на письма за пять минут и так далее.

    Излишняя бюрократизация: частое следование документированным процедурам, которое ведёт к куче бумаги. Те же тестпланы на каждый чих. А это описание каждого фильтра, в том числе типы данных в каждом поле интерфейса, длина поля и так далее. Обычно это решается примерами, а не полной детализацией.

    В одной компании не было человека с ответственностью за актуальный релиз, иногда срывались сроки по выпуску продуктов на две недели.

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

    7. Борьба с безопасниками.

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

    8. Не налажены коммуникации между разработчиками и аналитиками.

    Это настолько детский косяк, что повторяется на каждом пятом проекте. Просто аналитик написал, что нужно, разработчик разработал и через месяц показал готовое. Аналитик бегает в ужасе, потому что он имел в виду не это. Три недели из этого месяца разработчик работал зря, хотя мог бы показать часть проекта, а аналитик мог бы поинтересоваться, как там дела. Есть методологии, которые это просто закрывают, но проблема в том, что в данной ситуации обе стороны не понимают, зачем нужен проект, и как он идёт.

    9. Конференц-дривен девелопмент.

    Руководитель увидел что-то крутое на конференции, и это без оглядки внедрили. Через три месяца повторили. В итоге в отчёте красиво, а работа стоит.

    Из-за внутренних конференций ещё бывает доведение до результата по схеме «Всегда на 80% готово». На публичных отчётах — «Почти готово», и это бесконечно. Доведение до 100% никогда не случается. Почему? Ну, например, смотрите пункт 1.

    Отдельно отмечу недообследование сторонних систем. Читаешь статейку — вау, круто, давайте использовать, а потом только изучаешь, как. И сталкиваешься с массой ограничений, потому что вендор мёд в уши лил только на первых двух встречах. Мы тут сами наступили на грабли. Было внутреннее внедрение системы для интернет-магазинов документации по проектированию инфраструктур, в т.ч. ЦОДов для очень интересных объектов. Обнаружился кейс ограничения стоимости товара в 100 миллионов. Фишка в том, что по предметной области цены на единицу документа выше. И там же система должна была перелопатить для поиска индекс, а у нас есть вложения по 1 гигабайту в документы. И ожидаемое время индексации — один месяц. Вендор про такое не предупреждал.

    10. Страшно вносить изменения.

    Есть такое состояние проекта: нужен рефакторинг, приходите через месяц. Но при этом ни тестов, ни документов, ничего нет. И разработчики сидят: «Мы боимся вносить изменения, мы боимся всё поломать».

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

    Ещё заказчик может писать экономические описания на привычном ему языке. На том проекте мы дали некий псевдоязык-конструктор (набор стандартов), который потом конвертируется в данные аналитиков. В духе «Если Ваня на больничном, то он не сможет пойти на производство».

    И финальный аккорд. Кто-то ещё в одной компании кодит прямо на проде. «Тут один маленький скриптик, я знаю, что делаю». Спасибо тебе, милый человек, но если я тебя найду, то даже не знаю, что с тобой сделаю.

    В общем, высказался. Если узнали свои проблемы — пишите в почту oeremeev@croc.ru. У нас для крупного бизнеса есть почти бесплатные пилоты с экспресс-диагностикой (поиски бутылочных горлышек за 3-5 дней). Если кому-то у вас из бизнеса надо объяснить, что с техдолгом мириться нельзя, — тоже пишите, мы умеем это нормально считать.
    КРОК
    559,64
    IT-компания
    Поделиться публикацией

    Комментарии 104

      +60
      Остался только вопрос — а при чём тут Россия?
      Я за свои 10+ лет работы на серьезную компанию в США своими глазами видел наборы очень похожих историй. Кровавый энтерпрайз везде одинаковый вообще. И аджайл там тоже внедряют так, что в цирке потом никто не смеется.
        +2
        Вы правы, Россия в этом смысле не уникальна. И в том-то и дело, что следуя за мировыми трендами, зачастую с некоторой задержкой, никто не утруждает себя тем, чтобы взглянуть по сторонам и принять во внимание опыт тех компаний, которые уже прошли этот путь и набили шишки.

        Почти уверен, что такие поведенческие паттерны свойственны и США и Европе, но мы живем и работаем в России.
          +2
          В Японии не лучше ))) (а то и хуже чем в некоторых российских компаниях).
          +9
          Так это русская национальная привычка такая. Начинать с «Только в России...», а после указания на то, что в других странах тоже не всегда хорошо, лучшая отмазка «Я живу в России, меня волнует Россия».
            +3
            Уверенны, что только в России это национальная привычка?
            +1
            clickbait
            • НЛО прилетело и опубликовало эту надпись здесь
              +9
              Внезапно заказчик решил потребовать выдать ему исходный код. Как оказалось, у их имеющегося подрядчика были планы на то, что они проведут разработку софта, а потом будут продавать результат как SaaS по рынку. В договоре про код ничего не сказано.
              Я помню, нам в универе говорили, что в России по какому-то там госту-шмосту (ссылку не дам, не помню) при заказной разработке ПО исполнитель обязан передать заказчику исходники по умолчанию. И как по мне, это абсолютно правильно.
                0
                А что делать, если я прямо в машинных кодах пишу? Распечатка хекс-кодов за исходники сойдут?
                  –2
                  Если вы исполнитель заказа, то вы подписались не только его выполнить, но и выполнить на прописанных в договоре условиях.
                    +4
                    Мы тут обсуждаем случай когда в договоре не прописана обязанность передавать исходники.
                    Правомерно ли тогда требование заказчика предоставить исходные тексты ссылаясь на законы РФ? И может ли исполнитель отказать, говоря что он руками байты в екзешник пишет?
                      +2

                      Если он и правда руками байты пишет, то должен выдать экзешник, как исходник. Другое дело, что если он не руками байты пишет, то это обман заказчика и преследуется уже по другой статье (ну или ректальным криптоанализом, если в людях ошибся).

                        +3
                        С каких пор ГОСТ чему либо обязывает и стал законом РФ?
                        Гост это соответствие определенным требованиям, но если вы не делаете по госту, то можете и не соответствовать. А делаете или нет, это как раз у вас и будет указано в договоре.
                          0
                          Речь, видимо, об этом:
                          Вот вопрос на форуме:
                          «Компания разработала программу для ЭВМ на основании договора, по условиям которого заказчику передается исключительное право на эту программу. Обязана ли компания-разработчик передавать исходный код на программу? Ситуация 1: в договоре про передачу исходного кода ничего не указано.»

                          Ответ
                          «Да, обязана. В противном случае приобретатель не сможет реализовать свое право на модификацию программы (пп. 9 п. 2 ст. 1270 ГК РФ). Получится, что компания-разработчик передала только часть прав на программу, что не соответствует положениям ст. 1285 ГК Р. Ф. По договору об отчуждении исключительного права на произведение автор или иной правообладатель передает или обязуется передать принадлежащее ему исключительное право на произведение в полном объеме приобретателю такого права.»
                            0
                            Интересно, почему тогда автосалоны не обязаны передавать всю техническую документацию на продаваемые изделия, включая описания станков конвейерной линии? Вдруг пользователь «захочет модифицировать»?

                            Или вот если бы nVidia вела бы бизнес в россии...oh, wait…
                              +1

                              Как минимум потому, что речь про разработку на заказ, а вы привели примеры тиражного изготовления без заказчика.

                          +1
                          Исходики это «служебное произведение» в результате выполнения договора не выходящее за его рамки? Да. Значит принадлежит заказчику по умолчанию. А чем он пишет это не важно, пусть хоть как некоторые художники кисточкой вставленной в причинное место это делает.
                            0
                            Служебное произведение — это произведение, созданное работником в рамках своих трудовых обязанностей

                            Договор подряда (а речь именно о нём, судя по терминам Заказчик и Подрядчик) — это не трудовой договор, даже если подрядчик — физлицо.
                        +2
                        Абсолютно любой носитель сойдёт. Даже распечатка хекс-кодов. Вы главное передайте.
                          +10
                          Меня как-то раз просили сдать в архив распечатанный дамп базы. Вот прямо в бинарном виде. База была средненькая, гигов на 100. Но архивариуса вполне устроили 50 листов распечатанной абракадабры.
                            +26
                            Вместо организации подлога нужно было просто написать служебку следующего характера:
                            Дамп базы = 100 000 000 000 знаков. Ну ладно, сжалимся и сожмём до 30% от исходного. 30 000 000 000.
                            Лист А4 = 1 800 знаков.

                            Получается 17 млн страниц. Допустим напечатали с двух сторон. 8.5 млн листов. Каждые 500 листов весят 2.5 кг. 42 тонны бумаги.

                            Необходимо было попросить архивариуса во исполнение требований выделить железнодорожный контейнер, способный хранить 42т бумаги с учетом температуры и влажности.

                            Затем отправить очередную служебку завхозу или кто-там ведает закупками, что для распечатки 17млн страниц потребуется перезаправить лазерный принтер с ёмкостью тонера 10,000 страниц и, скажем, барабана 50 000 страниц (дорогой же принтер?). Необходимо запросить бюджет. В т.ч. выделить грузчиков с тележками для заполнения ж/д контейнера по мере распечатки.

                            ЛИБО, милостиво предложите, как альтернатива, купить флешку за $50.

                            Думаю, архивариус был бы счастлив принять правильное решение, а Вам не пришлось бы подставляться :-)
                              +4
                              Была подобная мысль, начальник отговорила. Вот как раз 50 листов с устным пояснением, что это < 1% от целевого результата убедили архивариуса, что не стоит доводить начатое до конца.
                              Но ей надо что-то предоставить в случае ревизии? У нее регламент. Пришлось идти «на подлог».
                              Это было в те прекрасные времена, когда каждое «электронное письмо», даже если это вообще не письмо, а передача файлов по шифрованной сети, требовалось распечатывать и сдавать в архив вместе с вложениями. Со временем нормативные документы переделали.
                            0
                            Конечно, это и есть исходный код.
                              –7
                              Вы не пишите в hex-кодах. Я даже думаю, что Вы их не знаете.
                                +1
                                Можно писать. Я, например, часто на smali пишу, да не такой сложный, но все же машинный язык тоже
                                +1
                                в ГОСТ 19.401-78. ЕСПД допускается:
                                символическая запись на исходном языке;
                                символическая запись па промежуточных языках;
                                символическое представление машинных кодов и т. п

                                Если кратко, да сойдут. Но это, если в договоре указано обязательное исполнение ГОСТ. А так могут что угодно прописать, хоть на камне высечь, если не расходится с действующим законодательством
                                  0

                                  Помню байку… Один ИП (индивидуальный предприниматель) выкатил претензию банку. Претензию выгравировал на гранитных плитах. ИП изготавливало надгробия, так что работа привычная. И выгрузили стопку "листов" на крыльцо краном.

                                +4
                                Сейчас передавать исходники… этого мало, очень мало! Нужны ещё инструкции по компиляции и сборке, а так же по внутренней модели данных и базу с системными настройками. Исходники — ничто, если нет базы. База без магических настроек — ничто…
                                  0
                                  Infrastructure as code, Configuration as code…
                                  Под СКВ должно находиться всё необходимое для развёртывания приложения в любом окружении с нуля, после клонирования. Не знаю насчёт передачи кодов и ГОСТов, по мне это современный, и единственно разумный подход.
                                  Благо инструментарий для поддержки такой концепции очень активно развивается последние годы.
                                    +2
                                    Ну вот сделает вам подрядчик проект с teamcity DSL прямо в коде. Где все настроено просто отлично, с автотестами, с автоматическом разворачивании тестовых окружений в облаке и так далее.

                                    Но вот у вашей компании лицензии на тимсити нет, аккаунты у вас в AWS а не гугл клауд — надо сильно переделывать, и вообще в Котлине, на котором Teamcity хранит свои настройки никто не разбирается, потому что проект на Nodejs, и что вы локально будете делать?
                                      0

                                      Вот по этим причинам я предпочитаю не использовать тимсити. Другие современные ci системы как раз ориентированы на полное управление продуктом и процессами через репозиторий.


                                      Конкретно в приведённом вами примере, лично я, в зависимости от роли. Договариваться с подрядчиком на берегу о критериях приёмки, либо вытаскивать проект из богомерзкого тимсити.

                                        0
                                        Вот по этим причинам я предпочитаю не использовать тимсити. Другие современные ci системы как раз ориентированы на полное управление продуктом и процессами через репозиторий.


                                        Ну вот сделает вам подрядчик проект с teamcity DSL прямо в коде

                                        Тимсити ТАКЖЕ как и другие CI системы может и умеет хранить все процессы в репозитории. Я же упомянул DSL. Тимсити даже поддерживает Котлин в качестве языка, на котором можно писать пайплайны и описание джобы, чтобы легко и автоматически создать проекты и таски в ней на другом тимсити с нуля.

                                        Инфраструктура-как-код — это означает, что она поддерживается как код — удобно, с версионированием, с централизированным хранением и простым способом бэкапа.
                                        То есть переразвернуть какие-то части с нуля можно быстро, и даже автоматизировано.

                                        Но инфраструктура-как-код не означает, что ее можно очень легко можно поднять и развернуть в другой компании. Бывает даже наоборот — если все переехало в код, многие уже и не знают как вообще собрать продукт без этого. А это означает что прежде чем настроить с нуля в других условиях, нужно глубоко разобраться в предыдущем коде.
                                  +2
                                  Иногда исходники — это просто исходники.
                                  А инфраструктура, на которой все это пишется, собирается, откатывается — это отдельная часть, которая к исходникам продукта отношения не имеет.
                                  И отдавая исходники, ты понимаешь что для того, чтобы банально собрать и протестировать продукт — там нужно будет потратить месяц работы девопса или нормального архитектора, чтобы разобраться что к чему.
                                    +1
                                    Вообще, не оговорить в договоре историю с исходниками и правами на использование результатов разработки — это верх некомпетентности.
                                      0
                                      Тут ещё такая прикольная тонкость есть, что исходники и права интеллектуально собственности на исходники — это очень сильно не одно и то же.
                                        0

                                        Ну не в России, а в СССР. А еще был в г. Калинине Фонд Алгоритмов и Программ, из давались сборники, хранящегося в этом фонде. И все это не чета нынешнему реестру отечественного ПО.

                                          –1
                                          Два раза в жизни была такая предъява. Распечатали исходники в HEX шестым кеглем, заверили каждый лист, сдали и попрощались.
                                          +5
                                          Прикол часто в том, что ваш (или чей угодно ещё) пилот не нужен. Люди, которые «работу работают» и так знают о бутылочных горлышках. Если вы сделаете пилот, то эти самые люди станут виноваты в этих бутылочных горлышках (ну не начальство или владельцы же, в самом деле).
                                            +1
                                            Штука в том, что к большой радости, уровень осознанности людей растет. И многие руководители не ставят перед собой цель искать виноватых, это не приближает их к результату в виде качественного конечного продукта/сервиса и тд. Им-то по голове стучат огого как за невыполненные комиты. И они это понимают. Поэтому фокус у них на оптимизации инструментариев/процессов и повышения эффективности тех ресурсов, которыми они обладают. И это реально рабочая история.
                                              +11
                                              Если бы это было так, то ситуация разрешалась бы опять же без вашего участия. Повторюсь, «рабочие руки» в большинстве случаев знают в чём проблема.
                                              Или вы думаете, разработчик, который пишет на проде рад этому? А может у него просто теста нет?
                                              А теста у него почему нет? Может потому, что в организации надо написать какую-то макулатуру вроде «технического решения», где описать сетевые структуры и т.п.?
                                              И почему же нет этого «важного и полезного» документа? Уж не потому ли, что разработчик должен его сам выродить, а все окружающие будут кривить морды и говорить «ой, тут что-то не по корпоративным политикам, тут что-то не понятно...»
                                              А документы надо согласовать может потому, что там «самый большой» захотел? Или потому, что бардак вокруг и не понятно где-что-почему-как работает, и люди прямо на прод пишут код?
                                              Вот он и замкнулся цикл. И все прекрасно всё знают. Но очередные «аджайлы по-русски» (прямо как у вас и описано) появляются, усугубляя ситуацию.
                                                +2
                                                Все, что вы пишете — правда. Это мы видим сплошь и рядом.
                                                Но то, что пишу я — тоже правда.
                                                И тут нет конфликта.
                                                Просто надо понимать, что для формирования потребности что-то поменять должны быть предпосылки. Она (потребность) не возникает на пустом месте и просто так. И «рабочие руки» в вашем примере зачастую не всегда могут эту потребность даже начать формировать. Ввиду разных обстоятельств (все устраивает, а сейчас заикнусь меня потом крайним сделают, что я умнее других? и тд). Потому что подсознательно каждый из нас понимает, что изменения устоявшегося положения дел, это не всегда приятно, а, как правило, наоборот.
                                                Потребность формируется уровнем выше под постепенным давлением того, о чем вы написали. И процесс этот не мгновенный. Но когда люди понимают, что что-то не так, они начинают эту историю копать и разбираться. Кто-то сам, кто-то приходит к нам. И мы помогаем.
                                                  +3
                                                  Нет, я же не спорю, что у нас менталитет такой, что «варягам» доверия больше, чем своим. И то что «Ванька» скажет — от того лишь отмахнутся, а когда тоже от «консалтеров/интеграторов великих и могучих» (а лучше ещё заморских) — то сразу надо тому же «Ваньке» на вид поставить и заставить сделать.

                                                  Тут не про потребность. А про то, что от пилота в вашем описании пользы для людей на местах действительно не будет. Будет только головная боль.
                                                    0
                                                    Все очень зависит от того как этот пилот будет проходить. Если, как часто бывает, придут консалтеры напишут много умных слов и уйдут — то да будет головная боль. Так как любая «лучшая практика» во-первых, все лишь рекомендация, а не строгий закон, во-вторых имеет границы применимости, т.е. пост и пред-условия, без выполнения которых превращается в цирк. А если консультанты постараются подружиться с людьми на местах и будут планомерно внедрядть новые процессы, то может и выйдет толк. Причем «подружиться» это, ИМХО, ключевое — иначе местные будут невольно саботировать процесс — никто не любит когда их учат наставлениями и приказами.

                                                    Про внедрение лучших практик у меня есть два примера — обе «внедрялись» с подачи заморского интегратора.
                                                    Первый про документацию — нужно документировать разработки производиемые в ERP(SAP). Вроде и нужно и даже полезно, результат — куча docx файлов в хранилище без индексации и поиска. Причем в этих файлах содержались по сути pull-requests(только к коду никак не привязанные), они не были поделены ни по бизнес-процессам, ни по модулям в системе, один и тот же класс мог упоминаться в десяткаях разных документов(про SOLID там никто не слышал). То есть если берешь какой-нибудь бизнес-процесс или кусок сервисного кода и пытаешься найти к нему документацию — то это бесполезная потеря времени.
                                                    Второй — аджайл, все круто, только заказчику забыли рассказать что это и зачем, а заказчику этот ваш MVP даром не сделася, ему подавай готовую систему, которую писать год минимум и она за это время естественно устареет. Хотя бы митинги с «я ничего не сделал» быстро отменили.
                                                      0
                                                      Из статьи:
                                                      пилоты с экспресс-диагностикой (поиски бутылочных горлышек за 3-5 дней)

                                                      Внедрения, о котором вы говорите в их пилотах, по-моему нет.
                                                  +2
                                                  очень часто разрабы выпрашивают тест окружение, а потом хренакс и оно становится продакшен без объявления войны, причем, что оно стало продакшен становится известно, когда разрабов попросили освободить тестовый стенд
                                              +2
                                              1. Штраф за ошибки в ПО, внесённом разработчиками.

                                              Штрафы, это, конечно, жестоко, но что плохого в том, что код перепроверяется вдоль и поперёк перед релизом вместо тестирования на проде и десятка патчей следом? Даже если в ущерб скорости разработки.
                                                +9
                                                Да, но кого штрафовать? Может, это менеджер наседал, мол, давай быстрее в прод, времени нет?

                                                Или тестировщик не проверил?

                                                Или аналитик неправильно расписал?

                                                Может, человеку вообще угрожали увольнением по статье и запугали, чтобы он побыстрее в продакшен вытащил?

                                                Да и любое ПО содержит ошибки. Все это знают. Мы лишь стараемся уменьшить количество ошибок, но не можем от них полностью избавиться.

                                                  0
                                                  штрафуют подрядчика поставщика кода, как он убытки будет в своей системе распределять его головняк. Но «попытки решить задачу» должны стоить дешевле чем «решение задачи». Если в договоре у вас «решение» и вы за «решение» платите и подрядчик деньги уже получил, то «процесс решения» это несколько иное. И он изначально оценился бы по другому. Или хотя бы предупреждайте по человечески заказчика что код не тестировали и стоимость тестов в продакшене прогнозируется меньше стоимости тестирования в разработке, что бы заказчик хотя б забекапился посерьезнее.
                                                  0
                                                  В соседней теме вообще советуют запускать код в проде без тестирования.
                                                  +1
                                                  1. Штраф за ошибки в ПО, внесённом разработчиками.
                                                  2. Естественно, любой релиз (даже мелкий) выпускается в десятки раз медленнее, чем мог бы.

                                                  Вы хотели сказать что софт в кои-то веки начали нормально тестировать? Ну а не как обычно -«время программиста дороже аппаратных ресурсов и релизы должны быть каждый день» и в продакшн.
                                                    +5
                                                    В общем, высказался. Если узнали свои проблемы — пишите в почту oeremeev@croc.ru. У нас для крупного бизнеса есть почти бесплатные пилоты с экспресс-диагностикой (поиски бутылочных горлышек за 3-5 дней). Если кому-то у вас из бизнеса надо объяснить, что с техдолгом мириться нельзя, — тоже пишите, мы умеем это нормально считать.


                                                    Я помню, у меня на одном месте работы основная проблема была в том, что выдали компьютер с глючным wifi адаптером, который постоянно зависал и терял сеть. Сколько я не просил его починить, в ответ слышал только крики и истерики. Вплоть до CEO доходило.

                                                    Ну вы же понимаете, что ни один CEO никогда не признается, что не смог организовать даже закупку техники.
                                                      +1

                                                      Неинтересная рутина — так было, так есть и так будет

                                                        +4
                                                        Кто-то ещё в одной компании кодит прямо на проде. «Тут один маленький скриптик, я знаю, что делаю». Спасибо тебе, милый человек, но если я тебя найду, то даже не знаю, что с тобой сделаю.

                                                        Такое в некрупных компаниях запросто может быть.
                                                        Если бизнес устраивает, что в штате есть только программист(ы) и сисадмин(ы) — почему нет?
                                                        Зависит от масштаба.

                                                          +5
                                                          Да и в крупных…
                                                          В общем то — в почти любых, где требуется максимальная скорость исправления косяков.

                                                          Я, как то, на собеседовании одном долго слушал о том, как поставлен процесс разработки, сколько кругов ада проходит задача для деплоя, как разработчики всё делают исключительно на тестовой среде… а потом:
                                                          -Ну, на прод у разработчиков есть доступ?
                                                          -(потупив глазки) Есть, конечно… надо же как то факапы фиксить.
                                                            0
                                                            А максимальная скорость исправления косяков требуется именно там, где болт положен на тестовую среду. Когда прод физически недоступен (например, посреди тайги на военной базе), то тестовая среда будет содержать уйму тест-кейсов, собираемых от пользователей, с нагрузочным тестированием. А когда можно что-то «быстренько» поправить, то тестовая среда заброшена, с устаревшими данными и т.п. В результате получается разработка через «авось»: ну на стейджинге вроде запустилось, а на проде проверим. Если что, поправим.
                                                              +10
                                                              Максимальная скорость исправления косяков требуется везде где требуется, независимо от положен болт на тестовую среду или нет. Чаще всего эта необходимость пропорциональна количеству денег/эквивалента денег которые теряются в случае факапа за время факапа.

                                                              А факапы на проде случаются. Количество тестов и прочей шелухи может их количество снизить, но не до 0%.

                                                              Соответственно и протокол по скорейшему решению таких проблем должен быть. И тут уже начинается компромис между скоростью, доверием к профессионализму сотрудникам и «штатным порядком деплоя»… и бизнес выбирает первое обычно.

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

                                                              И ничего о том, что тест заброшен или с устаревшими данными или про авось тут нет. Просто прагматика.

                                                              Если бизнес готов к исправлению критического или не очень бага через значительное время или оплате кроме дежурного программиста ещё и команды дежурных тестировщиков и QA — это хорошо, но что то я такое не часто видел (бывало, конечно, но обычно это или компании которым в достаточной степени всё-равно на клиентов или с оооочень толстым бюджетом).

                                                              ЗЫ: но есть, конечно, большая разница между «разработка на проде» (да, это чертовски сурово) и «доступ для хотфикса» (в известной степень допустимое решение). Из статьи непонятно к какому случаю относится «скриптик», но выглядит как хотфикс. )
                                                                +1
                                                                Не понимаю зачем доступ на прод для хотфикса?
                                                                  0
                                                                  А потому что не у всех есть инфраструктура деплоя. Часто выглядит так — деплоим редко(не аджайл ага), поэтому инфраструктуру автоматизировать не будем. Зато когда деплоим, то вылезает куча косяков, которые нужно фиксить вот прямо сейчас.
                                                                  Есть еще вариант, если пойти через имеющийся DI, то придется писать объяснительную какую, а если напряму в проде, то почему-то — не придется.
                                                                    0
                                                                    Окей, а какие варианты? )
                                                                    Провести полный цикл деплоя с тестированием,QA и прочими прелестями?
                                                                    Для этого нужны люди (которые могут отсутствовать на рабочем месте, а их присутствие в виде дежурных — деньги и время), и время.
                                                                    А если деплой полностью автоматический, то разницы в правках на тесте или на бою, в общем то нет, по большому счёту. (но тут ещё может быть косяк в самой системе деплоя или данных на бою и тогда ТТ).
                                                                      –1
                                                                      Для ясности — я говорю о серьезных конторах, а не о начинающих стартапах и бизнесах с одним-двумя разработчиками.

                                                                      1) Полный цикл деплоя занимает меньше времени, чем правка на проде руками.
                                                                      2) Доступа на прод у разработчиков нет, а девопсов которые умеют в программирование три с половиной человека.

                                                                      Если у вас не так, то у вас проблемы.

                                                                      Например, из реального. Программист поправил код на проде (питон скрипт) в пятницу вечером и пошел домой. А после него провели релиз, его изменения затерли — и сайт все выходные неправильно обрабатывал данные. Тут сложились сразу несколько ошибок — код не был закомичен в cvs, доступ девелопера на прод, правка руками на проде, пятница, релиз. И можно сказать, что его ошибка что он не закомитил, что у нас хорошие разработчики, они так не сделают. Но если вы менеджер проекта, тим лид или просто разработчик который общается с бизнесом, вы понимаете что это риск.

                                                                      PS Статья и коменты показали в каком плачевном состоянии индустрия.
                                                                        0
                                                                        Для ясности — я говорю о серьезных конторах, а не о начинающих стартапах и бизнесах с одним-двумя разработчиками.


                                                                        ну так и я о фирмах с штатом больше 100 разработчиков (иногда на порядок)

                                                                        1) Полный цикл деплоя занимает меньше времени, чем правка на проде руками.
                                                                        это по определению не так ) потому что кроме самого непосредственного внесения правок, ещё и полный цикл деплоя.

                                                                        2) Доступа на прод у разработчиков нет, а девопсов которые умеют в программирование три с половиной человека.
                                                                        =)) т.е. надо ещё и дежурного девопса держать?

                                                                        Например, из реального. Программист поправил код на проде (питон скрипт) в пятницу вечером и пошел домой. А после него провели релиз, его изменения затерли — и сайт все выходные неправильно обрабатывал данные. Тут сложились сразу несколько ошибок — код не был закомичен в cvs, доступ девелопера на прод, правка руками на проде, пятница, релиз. И можно сказать, что его ошибка что он не закомитил, что у нас хорошие разработчики, они так не сделают. Но если вы менеджер проекта, тим лид или просто разработчик который общается с бизнесом, вы понимаете что это риск.


                                                                        Все знают риски. А кто не знает — тем это быстро объяснят. Но те кто за это отвечают (чаще всего бизнес) предпочитают скорость решения бага возможными осложнениями. Особенно во время, когда больше части работников нет в доступе (выходной, к примеру) и держать дежурного QA, Тестировщика, Девопса, и разработчика (желательно ещё кодревьюера) причём способных поддержать ВЕСЬ проект (или каждую из его частей) и ждать пока фикс пройдёт все тесты, кодревью и задеплоится (что не так уж и быстро бывает, особенно если народ по удалёнке).
                                                                        И это вполне приемлимо, если правильно оформлять фиксы и потом спокойно и правильно доделать когда наступит рабочее время.

                                                                        А если исходить из того, что человек может быть членистоног и что то сломает — так он с тем же успехом выпустит фикс который пройдёт все тесты и опять положит прод (как тот, который положил), или QA неправильно что то сделает или ещё кто то в цепочке деплоя. Риски, в общем то, те же )

                                                                        Если у вас иначе — хорошо. =) Но чем длиннее цепочка — тем она длиннее.
                                                                          0
                                                                          это по определению не так ) потому что кроме самого непосредственного внесения правок, ещё и полный цикл деплоя.

                                                                          Я видимо не понимаю что вы на проде правите — скрипт какой-то? Тогда теоретически это может быть быстрее чем правильный релиз. Согласен. Только вероятность привнести новый баг становится выше.
                                                                          что то сломает — так он с тем же успехом выпустит фикс который пройдёт все тесты и опять положит прод (как тот, который положил)

                                                                          Ну нет же. Допустим вероятность того, что разработчик сломал что-то во время фикса в коде равна p > 0. Но есть еще вероятность q > 0 того, что он сломал что-то во время подключения (например подключился не на тот сервер, добавил лишний пробел или запятую, скопировал файл с line break виндовским из IDE, скопировал из IDE не ту версию скрипта и т.п.). Получили вероятность p+q > p.
                                                                            0
                                                                            Я видимо не понимаю что вы на проде правите — скрипт какой-то? Тогда теоретически это может быть быстрее чем правильный релиз. Согласен. Только вероятность привнести новый баг становится выше.

                                                                            Так скрипт уже поломан. Даже если там и появится новый баг — хуже уже не станет.


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

                                                                              0
                                                                              Я видимо не понимаю что вы на проде правите — скрипт какой-то? Тогда теоретически это может быть быстрее чем правильный релиз. Согласен. Только вероятность привнести новый баг становится выше.
                                                                              Ну да, скрипт или часть/модуль которую можно отдельно исправить без пересборки всего и вся.

                                                                              Ну да, риск увеличивается, хотя, если уже существующий сломанный «скрипт» прошёл в прод — значит риск что даже при правильном деплое что то будет сломано тоже велик )

                                                                              Ну нет же. Допустим вероятность того, что разработчик сломал что-то во время фикса в коде равна p > 0. Но есть еще вероятность q > 0 того, что он сломал что-то во время подключения (например подключился не на тот сервер, добавил лишний пробел или запятую, скопировал файл с line break виндовским из IDE, скопировал из IDE не ту версию скрипта и т.п.). Получили вероятность p+q > p.
                                                                              А есть ещё вероятность что где то в процессе деплоя есть ошибка, в процессе сборки, в людях которые этим занимаются и прочая-прочая.

                                                                              Между итоговым риском хотфикса человеком который это делал и понимает в чём ошибка сразу по живому против скорости и стоимости внеплановой выкатки изменений по штатному расписанию обычно (по моему личному опыту) выбирают первое. И в этом есть смысл ) Как в прочем и в обратном.

                                                                              ЗЫ: но разработчиков которые регулярно промышляют описанными вами вещами я бы и до теста не допускал, не то что на прод хотфиксы выкатывать.
                                                                            0
                                                                            я говорю о серьезных конторах, а не о начинающих стартапах и бизнесах с одним-двумя разработчиками.

                                                                            1) Полный цикл деплоя занимает меньше времени, чем правка на проде руками.

                                                                            В серьезных конторах согласование о разрешении деплоя на прод занимает неделю, пока все тикеты откроешь, аппрувалы получишь. А сам деплой да, может занять и секунды.
                                                                              0
                                                                              Согласен.
                                                                              Поэтому нет смысла экономить секунды, делая фикс на проде руками.
                                                                                0
                                                                                Экономится как раз эта неделя согласований и решений, особенно учитывая что в этом время проект стоит.
                                                                                  +1
                                                                                  Не неделя экономится, а процессы аудита вообще security policy как таковой отсутствует в проекте, что может привести к гораздо большим рискам, чем задержка отдельного релиза.
                                                                                    0
                                                                                    Может. А может и не привести.
                                                                                    Риски и издержки каждый оценивает по-своему.
                                                                                    Для кого то риски повторной ошибки при фиксе (и так же оперативно исправленной) куда ниже чем издержки от недельного выкатывания фикса в бой и простоя всей системы в течении этого времени. (который может пройти все тесты, как и предыдущая версия).
                                                                                      0
                                                                                      Повторная ошибка может быть не исправимой. Например удаление данных пользователей. Или рассылка автоматических сообщений пользователям. Или списание со счета пользователя.

                                                                                      Но в общем соглашусь, каждый оценивает риски для себя по своему.
                                                                                        0
                                                                                        Ну, тут зависит от компетентности того, кто исправляет. =)
                                                                                        Если бизнес верит, что перед внесением неисправимых изменений разработчик не озаботится бэкапом или возможностью отката, не отложит проблему как невозможную в разрезе его ответственности или не призовёт кого то для дублирования своих выкладок и вообще — не очень ответственный и адекватный человек… Ну что ж, тогда стоит пересмотреть кандидата на дежурство или риски и процесс внесения хотфиксов на бой )

                                                                                          0
                                                                                          Зовите меня когда нужно будет настроить процессы. :)
                                                                                          На всякий случай — я инженер, а не менеджер.
                                                                                            0
                                                                                            Собственно, настройка процессов тут не причём.
                                                                                              0
                                                                                              Или вы упорствуете просто чтобы доказать, что правы, либо у вас не настроены процессы разработки и доставки.
                                                                                                0
                                                                                                Эх-хе… ну давайте расскажите, как должны быть настроены процессы разработки и доставки что бы исправить скрипт на проде было быстрее через штатный цикл деплоя, а не напрямую.

                                                                                                *ну, допустим, закоментировать отладочный SELECT.
                                                                                                  0
                                                                                                  Вы смешали несколько моих высказываний в одно, может быть я сам неправильно выразился.
                                                                                                  Если у вас скриптовый язык, нет кубернетеса и доступ на прод сервер есть у всех подряд, то действительно быстрее руками. Но это небезопасно.

                                                                                                  Как сделать правильно — представьте, что доступ к проду будет обрезан через месяц для всех разработчиков. А деплой осуществляет команда девопсов, менеджера которой посадят на 10 лет если кто-то не из его команды сможет поправить код руками на проде. И дальше сводите время релиза к минимуму.
                                                                                                    0
                                                                                                    Ну так речь как раз о первом случае, когда можно внести локальные изменения и когда это зашибись как критично.
                                                                                                    Да и доступ, обычно, только у дежурного, а не у всех )

                                                                                                    А второй вариант — чаще всего тупо дольше и требует больше ресурсов на поддержание (хотя бы в виде дежурных и разрабов и девопсов и прочих участников выкатки).

                                                                                                    Но да, конечно второй вариант безопаснее, с этим никто и не спорит.

                                                                                                    Поэтому я и говорю — это вопрос выбора и рисков. Скорость vs безопасность. =)
                                                                                        +1
                                                                                        Может. А может и не привести.

                                                                                        Ну в таком случае, я могу заявить, что неделя может экономится а может и не экономится.
                                                                                          0
                                                                                          Только в случае если ошибка того же класса, что и была (которая прошла все тесты и задеплоилась) можно потерять и две недели в случае повтора.
                                                                                          А так — тоже мгновение на вмешательство в прод.

                                                                                          Тут не вопрос «может или не может», «ошибётся / не ошибётся», а вопрос издержек.

                                                                                          На одной чаше весов:
                                                                                          — Риск что человек, который хорошо понимает систему и сам же её разрабатывал сделает что то непоправимое и сломает вообще всё.
                                                                                          На другой:
                                                                                          — Содержание целого штата дежурных (разраб, техлид, тестировщик, QA, девопс, сисадмин, кто там ещё), причём по ставке выходного дня.
                                                                                          — Простой системы (чем она больше — тем она больше стоит) в течении прохождения задачи полного цикла выпуска или вообще — пока на работу не выйдут ответственные работники.

                                                                                          Вопрос лишь в величине рисков и издержек. По моему опыту — бизнес достаточно доверяет компетентности своих разрабов (или конкретных людей, к примеру тимлидам), что бы считать риск первого достаточно небольшим что бы избежать реальных и постоянных издержек второго варианта.

                                                                                          Если издержки на второй вариант не велики, а доверие к профессионализму сотрудников не очень велико — то решение будет иным и это будет тоже правильно. =)
                                                                                            +1
                                                                                            Если это хотя бы средний по размеру продукт, то в штате уже как минимум 20-30 человек.

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

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

                                                                                            По моему опыту — бизнес не должен доверять разрабам на слово.

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

                                                                                            — Содержание целого штата дежурных (разраб, техлид, тестировщик, QA, девопс, сисадмин, кто там ещё), причём по ставке выходного дня.

                                                                                            На самом деле это не нужно, если все изменения на прод выкатываются после тестирования. Риск, что выйдет что-то с ошибкой — в таких случаях стремится к нулю, а значит что на выходных релиз выкатывает релиз инженер, а все остальные — максимум on-call, на случай нестандартной ситуации.
                                                                                            Это как раз в случае прямого исправления чего-либо на продакшене, нужен целый штат на всякий случай, чтобы оперативно понять что и как чинить и восстанавливать.
                                                                                              +1
                                                                                              Если это хотя бы средний по размеру продукт, то в штате уже как минимум 20-30 человек.
                                                                                              ну допустим 150. в штате разработки.

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

                                                                                              Если это statefull продукт, то у него может быть база, и ошибка, которые вызывает изменения прямо на проде, может привести крупным проблемам, которые не так легко откатить назад.
                                                                                              Особенно если база большая, а операций много. Там даже банальное восстановление из бэкапа может занять часы, при этом надо еще разобраться можно ли откатываться с потерей текущих операций и как это правильно все сделать и вообще сразу снежный ком.
                                                                                              Да, конечно. При исправлении проблемы такое странно будет не учитывать.
                                                                                              По моему опыту — бизнес не должен доверять разрабам на слово.

                                                                                              Если бизнес не доверяет разработчикам, то я даже не знаю… отдавать сторонним специалистам проверять и ревьюить код? =)
                                                                                              Конечно бизнес должен доверять программистам. Но это не значит, что программисты не должны прикрывать свои пятые точки и защищать бизнес.

                                                                                              И если риск проблем на продакшене стоит денег/репутацию, все изменения должны проходить через тестовый енвайрнмент и как минимум «четыре глаза».
                                                                                              Ну, с этим никто и не спорит.

                                                                                              Вопрос в хотфиксах и исправлении критических ошибок. И тут стоит уже выбор: тратить время и средства на содержание итп-итп-итп я это уже писал. =)

                                                                                              На самом деле это не нужно, если все изменения на прод выкатываются после тестирования. Риск, что выйдет что-то с ошибкой — в таких случаях стремится к нулю, а значит что на выходных релиз выкатывает релиз инженер, а все остальные — максимум on-call, на случай нестандартной ситуации.


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

                                                                                              Это как раз в случае прямого исправления чего-либо на продакшене, нужен целый штат на всякий случай, чтобы оперативно понять что и как чинить и восстанавливать.
                                                                                              т.е. что бы исправить что то на проде этот штат не нужен, а что бы исправить то что кто то исправил на проде — нужен?
                                                                                                +1
                                                                                                Если бизнес не доверяет разработчикам, то я даже не знаю… отдавать сторонним специалистам проверять и ревьюить код? =)
                                                                                                Конечно бизнес должен доверять программистам. Но это не значит, что программисты не должны прикрывать свои пятые точки и защищать бизнес.


                                                                                                Не так поняли, или я не так выразился. Дело не в доверии между людьми
                                                                                                Дело в риске допустить человеческую ошибку, от которой никто не застрахован.
                                                                                                Поэтому практики «четыре глаза», «пулл реквесты с обязательным review», автотесты и вообще прогон на тестовом энве — как раз и уменьшают вероятность того, что человеческая ошибка прокрадется на продакшен.

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

                                                                                                Ну как-то эта ваша фраза уже конфликтует с тем, что

                                                                                                «значит в каждой команде должен быть такой человек.»
                                                                                                «при исправлении проблем с базой и откатом данных понятно что надо будет это учитывать»

                                                                                                Если по вашим словам нужно срочное исправление прямо на проде, а например одного человека который все знает не существует, то вот вам уже и консилиум из самых знающих представителях каждой команды, плюс та же проблема с откатом данных в базе и все это превращается в вопрос — что значит
                                                                                                И тут стоит уже выбор: тратить время и средства на содержание итп-итп-итп я это уже писал. =)


                                                                                                Да при ваших 150 разработчиках, содержание CI системы с автоматической сборкой, тестированием и деплойментом будет стоить менее 1-2 зарплат этих разработчиков, то есть 1-2%.

                                                                                                  0
                                                                                                  Не так поняли, или я не так выразился. Дело не в доверии между людьми
                                                                                                  Дело в риске допустить человеческую ошибку, от которой никто не застрахован.
                                                                                                  Поэтому практики «четыре глаза», «пулл реквесты с обязательным review», автотесты и вообще прогон на тестовом энве — как раз и уменьшают вероятность того, что человеческая ошибка прокрадется на продакшен.

                                                                                                  Прошу прощения, это я немного поёрничал.
                                                                                                  Но — на проде через все автотесты уже прошла одна ошибка, что мешает и второй так же пройти? Шанс, в общем то так же велик как и человеческая ошибка (учитывая что эта ошибка уже пролезла на прод), а ресурсы и время будет потеряно.
                                                                                                  Но если шанс оценивать иначе — то и вывод иной )

                                                                                                  Ну как-то эта ваша фраза уже конфликтует с тем, что

                                                                                                  «значит в каждой команде должен быть такой человек.»
                                                                                                  «при исправлении проблем с базой и откатом данных понятно что надо будет это учитывать»

                                                                                                  Если по вашим словам нужно срочное исправление прямо на проде, а например одного человека который все знает не существует, то вот вам уже и консилиум из самых знающих представителях каждой команды, плюс та же проблема с откатом данных в базе и все это превращается в вопрос — что значит
                                                                                                  Да нет, не конфликтует. Какой консилиум если команды разные? Парни из других команд обычно в данном проекте не разбираются — о чём с ними совещаться? так что достаточно дежурного от команды/проекта.

                                                                                                  Да при ваших 150 разработчиках, содержание CI системы с автоматической сборкой, тестированием и деплойментом будет стоить менее 1-2 зарплат этих разработчиков, то есть 1-2%.
                                                                                                  1-2 зарплаты на поддержание системы, ещё столько же на тех кто будет этим пользоваться и штат дежурных по её запуску. 3-4 зп — это ещё целая команда. =)
                                                                                                    0
                                                                                                    Иногда то что соседняя команда не разбирается в вопросе это даже большой плюс — они могут взглянуть на проблему незамыленым глазом и сказать «да у вас тут и тут хвосты торчат метровой длины, а вы и не замечаете».
                                                                                                      0
                                                                                                      И будут посланы далеко и надолго. =)
                                                                                                      1. В нерабочее время во время исправления бага на проде — это СОВСЕМ НЕ ТОТ момент, когда нужно слушать сомнительные заявления о техдолге и оптимальном способе реализации людей, которые не в курсе архитектуры и объектов системы.
                                                                                                      2. Процесс «тыканья грязным пальцем» в чужой проект должен проходить в штатном порядке (если такое необходимо), с поставленным подходом, иначе это будет не конструктив а срач. =)

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

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

                                                                                                      Так что -пусть пилят свой проект и не лезут, если не звали. Давать советы другим командам и тыкать в их ошибки — не их задача.
                                                                          0
                                                                          Был случай, когда всё отлично отработало на тестах, было показано заказчику, заказчик похлопал в ладоши, развернули на проде у заказчика… И ничего не работает.
                                                                          Потому что на тест заказчик выдал старую структуру БД с невалидными данными, а ключевые колонки в таблицах молча обрезал и не сказал об этом.
                                                                          Потому что там секретные данные, их нельзя передавать. И sha2 к ним нельзя. И забить случайными данными нельзя, потому что секретно.
                                                                          Пришлось пепеписывать и тестить на месте — и фронт, и бэк.
                                                                          Зато какой чудесный код, когда приходит Высокое Начальство и в честь праздника наливает… Отказаться нельзя — оскорбление начальства. Не кодить нельзя, нужно срочнобыстро доделать, заодно и показать, что мы делаем всё возможное.
                                                                      0
                                                                      Живой пример.
                                                                      Интеграция. Функционал на создание/обновление бизнес объектов с именем по определенному паттерну.
                                                                      2 месяца разработка-тестирование
                                                                      Клиент посмотрел, сказал все отлично, но паттерн нужно немного поменять.
                                                                      Паттерн захардкожен, так как зависит от многих параметров, и не должен в принципе меняться.
                                                                      Решение — скриптик обдейта в базе. Что в этом плохого?
                                                                        0

                                                                        Например, hh.ru, судя по их статье, практикует подобное. Если верить wikipedia, в декабре у них было 683 сотрудника (не знаю, насколько это много или мало).

                                                                        +16
                                                                        Олег, это же не документация.

                                                                        Ну, например, смотрите пункт 1.


                                                                        А чём там говорилось? Аффтар верит, что я помню все эти пункты?

                                                                        Ок, надо пролистать к пункту 1. А где же он? Не в начале текста. Абзац, абзац, абзацина со перечнем страшных ужасов разработки… а, вот. Про штрафы за баги.

                                                                        Теперь надо вспомнить, где я был в тот момент, когда этот чёртов первый пункт был упомянут…

                                                                        Да ёпт!

                                                                        А потом они ходютЪ и говорят, что у кого-то процессы не налажены…
                                                                          +5
                                                                          Штраф за ошибки в ПО, внесённом разработчиками.
                                                                          Недавно расследовал баг, что именно это и захотелось сделать: код вызывал SQL с картезианским джойном, получал в сотни раз больше записей, чем было в таблицах, а пототм средствами Java избавлялся от дупликатов. Код писал подрядчик, который специализируется на Java-разработке, крутые ребята, если не брать во внимание этот прокол. До сих пор ломаю голову, как такое может быть написано человеком…
                                                                          Клиент, кстати, сказал пока не фиксить, так как есть более приоритетные задачи. Вот такой он, ентерпрайз…
                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                              +8
                                                                              Если кому-то у вас из бизнеса надо объяснить, что с техдолгом мириться нельзя, — тоже пишите, мы умеем это нормально считать.

                                                                              — Коду под сорок лет. Около 10К человекочасов техдолга на Коболе. Древние Никсы. Никто не хочет платить за грейды даже железа, которое соревнуется с нами по возрасту, про софт вообще молчим. Кобол програмки интерфейсят с миром через шелскрипты и даже курлят всякие API сервисы. Под сотню больших, средних и малых бизнесов, на каждом свои заточки и кто-то обязательно накодил маленький или огроменный скрипт на проде. 56К Модемы стоят местами до сих пор. Не Россия, даже не СНГ, дальнее забугорье.
                                                                                0
                                                                                Насколько я понимаю, ERP можно протестировать только нагрузочно, так как полный набор функциональных тестов на все комбинации исходных данных будет стоить как сама ERP.
                                                                                  +1
                                                                                  кодит прямо на проде

                                                                                  Лучший тестер — финальный пользователь, это всем известно. Ну и так-то можно написать скрипт без ошибок, если ты — профессионал и знаешь систему.
                                                                                    0
                                                                                    Вообще тестировщик должен быть грамотней программиста в предметной области, попробуй протестировать функцию (x) => 1/x если у тебя двойка по математике. Тестирование в особых точках — отдельная наука, а без нее большинство модульных тестов — просто дань моде, еще и небесплатная.
                                                                                    0
                                                                                    Заказчик — тоже немаленькая компания — накатывает релизы ERP. А прикол в том, что система такая здоровая, что на полной базе или чём-то похожем её тестировать негде. Просто нет инфраструктуры. Точнее, есть, но нельзя сделать нагрузочный тест, только мелкие локальные вещи проверяются. Релиз встаёт — и никто не знает, как он себя поведёт на деле. Один раз всё знатно так упало, когда релиз повёл себя не так, как хотелось. В итоге позвали нас смотреть, что можно сделать. Мы обсудили, что они хотят посмотреть HP Perfomance Center, сделали пилот, потом интегрировали, обучили, поставили. Теперь релизы — через него. Эти нормированные операции тестируются, сводная аналитика по SLA по операциям.

                                                                                    Если честно, непонятно что сделали вы такого чего не мог сделать Заказчик.
                                                                                      0

                                                                                      У заказчика просто небыло ресурсов готовых этим заняться, иногда проще купить экспертизу на время...

                                                                                      0
                                                                                      Борьба с безопасниками.

                                                                                      У вас это тоже присутствует. В смысле, присутствуют безопасники, которых приходится потом обходить. Вот за каким надом вместо нормальных VPN-решений для доступа к интеграционному стенду в одном из проектом вы решили Stonesoft SSL использовать?


                                                                                      И финальный аккорд. Кто-то ещё в одной компании кодит прямо на проде. «Тут один маленький скриптик, я знаю, что делаю».

                                                                                      А это не может быть последствием слишком долгих деплоев? Когда полное развертывание системы занимает 9 часов и может окончиться неудачей из-за стечения обстоятельств (привет, Sharepoint!), а работать скрипт должен был уже вчера...

                                                                                        +2
                                                                                        Эх, производство. Задачи писали в расшаренный Excel. Начальству потребно было сделать БД где хранились бы наименования деталей, агентов, и т.п. Можно за месяц в Access полностью под себя сделать, но нет, будем покупать CRM за 10.000$+ плюс полгода внедрения… Стоило заикнуться что можно проще и под себя: был послан нахер менеджер лучше знает.
                                                                                          +1
                                                                                          1. Откаты.
                                                                                          2. Ответственность. Если делаем своими силами — значит подписываемся под смертным приговором и пожизненная поддержка «изделия». Кто этого захочет? Кроме того, в случае ошибки или факапа есть на кого сослаться — это подрядчики налажали…
                                                                                          «изделие» собственного изготовления это всегда головная боль и все шишки на голову, поэтому менеджеры чаще и не хотят брать на себя такую ношу.
                                                                                            +1

                                                                                            Есть ещё одно, вроде и не откат и не ответственность, з.п. и важность конкретного менеджера часто зависит от денежного потока на котором он сидит, и чем "толще" этот поток, тем важнее менеджер, а если всё можно за месяц и без него то зачем ему платить?

                                                                                          +2
                                                                                          на одну болванку вообще аниме записано

                                                                                          Какое именно аниме? Очень интересно.
                                                                                            0

                                                                                            Не знаю, как программиста прогающего на проде — а вот тех, кто "следует мировым трендам" — перестрелял бы…
                                                                                            Но, как в том анекдоте:


                                                                                            • Что вам мешает быть самим собой?
                                                                                            • Правила этикета и уголовный кодекс…

                                                                                            Увы…

                                                                                              0
                                                                                              писал код в Notepad.exe, потом кидал в компилятор без ошибок

                                                                                              Хы, я в армии написал кросс-компайлер С для БК-0010(СМ4 ЭВМ) и линкер.
                                                                                              Когда дембельнулся — набил это все, скомпилялось без ошибок.
                                                                                              Только на БК уже не нужно было переносить.

                                                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                              Самое читаемое