Назад | Перейти на главную страницу

Что вы хотите, чтобы разработчики поступали иначе?

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

Во-первых, мне очень жаль. Во-вторых, что вы хотите, чтобы я и другие разработчики, с которыми вы имеете дело, поступали иначе? Что могло бы облегчить вам жизнь, вызвать меньше проблем, стимулировать сотрудничество и уменьшить количество сбоев, проблем с производительностью и кошмаров конфигурации?

  1. Подумайте и создайте безопасность с нулевого дня.
  2. Используйте контроль версий для всего: исходного кода, документации, конфигурации и т. Д.
  3. Документация, документация, документация.
  4. Чистая установка и удаление с использованием упаковки, родной для платформы
  5. Отделяйте данные конфигурации от библиотек и исполняемых файлов
  6. Поддержка параллельного запуска разных версий для тестирования и миграции
  7. Надежное настраиваемое ведение журнала
  8. Легкий, точный и безопасный мониторинг
  9. Контрольные точки приложения и резервное копирование
  10. Как ваше приложение реагирует на проблемы: нехватка памяти, переполнение файловой системы, отключение сети, отсутствие / повреждение файлов конфигурации, временной сдвиг?
  11. Всегда используйте отдельные среды разработки, тестирования и производства. Со всем бесплатным программным обеспечением для виртуальных машин нет оправдания!

Помните, что ваше приложение, вероятно, имеет больше состояний, чем работает или не работает. Нарисуйте диаграмму состояний. Большинство приложений имеют такие состояния, как:

  • вниз
  • инициализация
  • восстановление
  • работать, но не принимать
  • ожидание
  • контрольно-пропускной пункт
  • обработка
  • Заканчивать
  • Выключение
  • вниз

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

Отличить "пользователя" от СА.

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

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

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

Одно из моих пожеланий - включение правильных сообщений в исключения и коды ошибок. Совершенно непонятно для тех, кто не разработал приложение, что за JimmyNotAtHomeException: it's late! средства.

Но такое сообщение, как Unable to find jimmy - initial manual call_mother procedure очень полезно.

Привлекайте нас на раннем этапе проекта. Как и в самом начале, на стадии функциональной спецификации.

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

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

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

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

Общение, общение, общение. Каждую проблему между системным администратором и разработчиком практически всегда можно отследить до отсутствия связи. Если до проекта системные администраторы (или их представители) и разработчики собрались вместе и провели хорошее обсуждение фреймворка, СОООООООООО многих проблем можно было бы избежать в будущем. Я не могу сказать вам, сколько вещей испортилось, потому что вы разрабатываете всех на одном компьютере в разработке только для того, чтобы смотреть, как он горит в продукте, потому что приложение затем разделяется на сервер приложений + сервер БД + сервер интерфейса и т. Д. Престижность за поднятие этой темы.

Не будьте элитарным.

"Не трать мое время, приятель. Ты просто системный администратор собачьего тела; я написать программное обеспечение и ты просто обслужите его. Так что просто заткнись со своими мелочными заботами и делай, как я говорю, хорошо? "

Однажды разработчик сказал мне эти слова (1). По электронной почте. Копирование в большую группу рассылки. Смысл был очевиден: как разработчик он был властелином всей вселенной программного обеспечения; и я был просто поденщиком, нанятым для выполнения задач, слишком тривиальных для него, чтобы тратить на них свое драгоценное время. Конечно, это почти наихудший пример, но вы знаете, я слышал сильные и слабые отголоски этого комментария от ряда разработчиков как до, так и после (2).

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

Я понимаю, что твоя работа и твои навыки отличаются от моих. Я уважаю твои способности. Надеюсь, вы ответите на мои вопросы, даже если они кажутся вам элементарными и глупыми. Я с радостью отвечу на эту любезность!

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

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


(1) Он также настаивал на том, чтобы его программа (инструмент для написания и управления требованиями к программному обеспечению) требовала прав администратора домена для установки и запуска. Это было крупный риск безопасности.

(2) Я также работал со многими замечательными разработчиками, которые могли обучать, когда необходимо, и учиться, когда необходимо.

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

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

Обсудите проблемы с производительностью с системными администраторами. Честно говоря, только системные администраторы способны правильно интерпретировать показатели производительности системы. Я видел, как разработчики решали, что в Linux всегда происходит утечка памяти, потому что количество свободной памяти, указанное как «свободная», всегда уменьшается, даже после 10-го раза, когда объясняется вывод «свободно».

Не делайте выводов, не обсудив это с системными администраторами. Я видел, как разработчики зацикливались на таких теориях, как «базы данных всегда привязаны к диску» (они не знали, что iostat вообще существует), «RAID 5 быстрее для транзакционных рабочих нагрузок» (на основе воспоминаний об одной системе баз данных, которая была перемещена от одной аппаратной платформы к другой - это была рабочая нагрузка с интенсивным чтением, решение RAID5 имело все больше и более быстрых дисков, распределяемых по большему количеству контроллеров. Но они забыли эти детали и запомнили только вывод.)

Не придумывайте решение системной проблемы, не обсудив его с системными администраторами. Я работал в одной патологической среде, когда разработчики разрабатывали решение и приходили просить небольшую помощь в реализации. Члены группы Unix, кроме меня, главы группы Unix и его босса, хотели относиться к разработчикам как к «клиентам», а не как к сотрудникам, пытающимся обеспечить функционирование общей инфраструктуры. Всегда быть правым покупателем означало не задаваться вопросом, что он делает и почему. Я был единственным, кто настаивал на описании проблемы, чтобы можно было найти правильное решение. Не действуйте таким образом, чтобы создать патологическую среду, подобную этой. Это не принесет чистой выгоды - вместо этого системные менеджеры будут действовать в обороне, и все пострадают.

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

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

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

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

Поймите, что есть разница между «медленно отвечать» и «совсем не отвечать».

Если с приложением связаны межсерверные взаимодействия, включите хотя бы одного системного администратора на этапе проектирования. Кроме того, четко документируйте зависимости от других служб: SQL, SMTP, HTTP и т. Д. Не заставляйте нас гадать, что вы делаете, иначе мы не сможем вам помочь, когда что-то работает не так, как вы ожидали.

Настраивайте и выкладывайте вещи предсказуемым образом с предсказуемыми способами их изменения для ОС, для которой вы разрабатываете. Это значит все. Например: OpenLDAP имеет странный способ определения лог-уровней; некоторые серверы IMAP даже не имеют файлов конфигурации, но должны иметь скомпилированные параметры; некоторые пакеты хотят, чтобы их файлы находились в одном конкретном пути к каталогу, что неизбежно нарушит соглашения конкретной операционной системы. Все эти штуки на моих обычных конфигах выглядят как бородавки.

Это общее правило, но не думайте, что вы особенный, и, следовательно, можете нарушить общие соглашения о том, как программные пакеты обычно работают на вашей платформе, если только вашему программному обеспечению не требуется веская причина. «Я твердо убежден, что так и должно быть» - недостаточно, чтобы нарушить обычную установку; Причина должна быть связана с функцией, которую пытается выполнить ваше программное обеспечение.

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

У Adobe исторически были установщики, которые было настоящей болью работать с; пожалуйста, цельтесь выше!

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

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

Помимо всего остального здесь ...

  • Спросите смоделированную производственную среду (сервер разработки или виртуальную машину с той же конфигурацией, что и живой сервер), а затем используйте ее для тестирования процесса выпуска. Затем предоставьте нам этот процесс выпуска, включая список изменений и порядок, в котором они должны быть применены (т.е. 1. войдите в режим обслуживания, 2. примените обновление SQL, 3. источник обновления до версии X, 4. выйдите из режима обслуживания, 5. молиться)
  • Убедитесь, что у вас есть режим обслуживания, который может выгнать пользователей для сохранения целостности данных. Вы же не хотите, чтобы мы запускали большое обновление системы на нескольких серверах, когда пользователи вошли в систему и выполняли транзакции ... в большинстве случаев это рецепт сбоя.
  • Используйте несколько стандартизированную модель разработки. Например, все наши новые приложения на работе (веб-группа) используют Zend Framework.
  • Предоставьте нам журналы изменений, которые мы можем прочитать, включая список исправленных ошибок, которые мы можем найти, чтобы получить представление об объеме изменений. Иногда мы можем выявить потенциальные проблемы только потому, что у нас другая точка зрения.

Дизайн для операций.

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

Да, и постарайтесь быть 64-битным, где возможно, и многопоточным тоже :)

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

Когда они входят в процесс разработки, еще не поздно, но может пройти некоторое время, прежде чем они смогут так далеко изменить свою точку зрения; они не осознают, насколько абстрактно они рассматривают кодовую базу, пока не будут вынуждены противостоять ей. По их мнению, это просто «компонент». Особый интерес представляет то, как он будет развернут в ранее существовавший окружение, работающее с предыдущей (или более старой!) версией программного обеспечения. Обсуждения развертывания могут оказать существенное влияние на то, как адаптируется архитектура для размещения новой функции.

  • Не развивайся без спецификаций
  • Документируйте (или убедитесь, что те, кто это делает, делают это точно)
  • Не бойтесь поддерживать клиента (как более высокий уровень поддержки)

Книга Отпустите! есть хорошая подборка ужасов о том, что может пойти не так в процессе производства. Его чтение может дать вдохновение / идеи для проектирования с учетом операций. (Его написал Майкл Найгард, который работал как над разработкой, так и над операциями.)

1) Файл журнала, в котором подробно регистрируются ошибки. или хорошая система отслеживания ошибок, такая как ELMAH.

2) Подробная документация по установке, внедрению и руководство по SA.

3) Плюс упомянутые выше вещи из других замечательных SA. :)

Это все, о чем я могу думать сейчас.

Мне нравится то, что я еще не видел, - это настраиваемое. Если у вас есть приложение, использующее какой-либо конфигурационный файл, сделайте все настраиваемым.
В своей компании я написал простое приложение, которое будет экспортировать часть нашей базы данных. На следующей неделе я его переписывал, чтобы можно было отключить небольшую часть. С тех пор каждую неделю мне приходилось переписывать детали и перестраивать его, чтобы изменить небольшую особенность. Я только что добавил XML-файл конфигурации, и теперь его стало проще развернуть заново.
Я люблю файлы конфигурации.

Желаю, чтобы разработчики лучше отделились от задач QA. Я думаю, что это хорошо, когда разработчик может создать несколько модульных тестов для проекта, над которым он / она работает, но было бы неплохо, если бы эти тесты были переданы QA. На самом деле, приятно, когда разработчики немного помогают QA-инженерам, потому что в конечном итоге это приносит пользу DEV.

Убедитесь, что это поддерживается: в дополнение ко всему остальному, упомянутому здесь, посмотрите этот пост на SO - https://stackoverflow.com/questions/205374/what-are-the-core-elements-to-include-in-support-documentation/