Аврал: как спланировать 14 часов работы в день, чтобы не выгореть раньше времени. Неочевидные моменты в работе с битриксом


Неочевидные нюансы Битрикса

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

Под катом разбор некоторых таких моментов.

Редактирование профиля пользователя на Корпоративном портале через публичную часть

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

Просмотр документов в браузере

Проблема: в модуле «Библиотека документов» имеется функция «просмотр документов» популярных форматов типа *.doc и *.pdf. Которая, однако, не работает (возможно, уже исправлено). Браузер просто показывает иконку загрузки, но документа нетРешение: в ходе изучения ошибки стало понятно, как этот просмотр вообще должен работать: при загрузке документа в Портал он загружается также и в Google Drive, вероятно, в какую-то временную директорию. Потом ответ, возвращаемый API Гугла и используется в качестве предпросмотра. Только вот ответ загружается неправильно, с ошибкой 302 и без какого-либо содержимого. Сотрудники техподдержки предложили решить проблему, установив обновления бета-версии, но, сопоставив возможные риски поломки всего вообще после установки нестабильного обновления с риском просто не просмотреть документ онлайн, мы пришли к решению: отключить предпросмотр. Документ все еще можно прекрасно скачать и просмотреть на клиенте.Кстати, обратите внимание, что, несмотря на ошибку при загрузке, из запросов к гуглу вполне можно достать работающую ссылку на документ в Драйве. Так что, есть немаленькая вероятность, что чьи-то «секретные документы» лежат не только в Портале

Права и перенаправления административной части

Проблема: При переходе в административную часть сайта у сотрудников, входящих в определенную группу, происходит перенаправление на неустановленную страницу, на которой отображаются только счетчики посещаемости, все остальное содержимое страниц отсутствует. Кроме того, эти счетчики установлены в шаблонах внешней части сайта, и не должны, теоретически, появляться при работе с административной частью.Рабочий стол при переходе появляется на долю секунды, затем происходит перенаправление (либо, возможно, перезапись страницы в браузере, что тоже непонятно).При переходе на любую конкретную страницу административной части, кроме Рабочего стола, все работает нормально у всех пользователей, которым вообще доступна административная часть.У пользователей, входящих в группу с полными административными правами, никакого перенаправления или перезаписи не происходитРешение: Разрешить данной группе пользователей чтение файла /bitrix/gadgets/bitrix/rssreader/getdata.php (Гаджет «Новости 1С-Битрикс», выводимый по-умолчанию на Рабочий стол). Именно он приводит к такому эффекту. Также имеет смысл разрешить чтение /bitrix/gadgets/bitrix/rssreader/ и всей папки /bitrix/admin/. Что, в общем, логично, но не объясняет, почему запрещение доступа к гаджету ломает все напрочь.

«Кук»

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

Многосайтовость на поддомене

Проблема: после успешного запуска второго сайта на поддомене первого внезапно оказывается, что оба сайта стали отдавать контент первого, а вот меню отдают по мере кеширования: обновился кеш второго сайта — на первом появилось меню второго, обновился кеш первого — все наоборот…Решение: Вообще, решить большую часть проблем многосайтовости можно с помощью этой статьи: dev.1c-bitrix.ru/community/blogs/howto/336.php но именно данная проблема оказалась очень интересной. Ошибку вызвало… изменение сортировки файлов. Случилось так, что раньше у второго сайта было значение сортировки «10», а у первого — «20». После произведенных изменений (старый второй сайт уехал на другой домен и новую копию Битрикса, а на его место в старом встал филиал первого на поддомене) логично было и поменять индекс сортировки, так как второй сайт является региональным представительством первого, а не наоборот. Но оказалось, что с системой многосайтовости это не совместимо — тут же появилась описанная проблем. Изменение порядка сортировки на обратный мгновенно ее решило.Мне повезло, я догадался, что случилось, потому что не так уж много времени и произведенных операций прошло от причины до обнаружения следствия. Чисто технически, я могу себе представить причины, по которым это произошло: парсер идет сверху вниз, и более общие условия (основной домен) добавляются к частным (сайт на субдомене), а вот в обратном порядке добавления уже не происходит, так как все субдомены считаются частью основного и, соответственно, к ним применяются только его правила. Но очевидно ли это вообще?

Заключение

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

Автор: lutov

Источник

www.pvsm.ru

Искусственный интеллект, вызовы и риски – глазами инженера

Добрый день, коллеги. Сегодня хочется трезво посмотреть глазами инженера на так популярные сейчас искусственный интеллект и Deep learning, упорядочить, выстроить факты и выработать выигрышную стратегию – как с этим … взлететь, пролететь и не упасть кому-нибудь на голову? Потому-что, когда дело от лабораторных моделей на python/matplotlib/numpy или lua доходит до высоконагруженного production в клиентском сервисе, когда ошибка в исходных данных сводит на нет все усилия – становится не то, что весело, а даже начинается нумерологический средневековый экстаз и инженеры начинают сутки напролет танцевать, в надежде излечиться от новомодной чумы )Танцующие инженеры, тщетно надеющиеся исцелиться

Современная разработка

Полезно для начала вспомнить, как в принципе устроена современная разработка программного обеспечения. За основу, как правило, берутся классические, хорошо изученные в «прошлом веке» алгоритмы: поиск, сортировка и т.д и т.п. Любимые всеми СУБД – хороший пример бородатых, тщательно проверенных и изученных классических алгоритмов (да простят нас Кодд и Дейт за такую попсу).

К алгоритмам добавляются согласованные сообществом инженеров (хотя нередко ни с кем не согласованные, продвинутые злой силой) – стандарты: сеть (DNS, TCP/IP), форматы файлов, сервисы операционной системы (POSIX) и т.п.

Ну и, конечно, языки. В последние годы, к сожалению, в этой области началась какая-то унылая ерундистика: добавляют-убирают автоматические геттеры и сеттеры и автоматически вводят-выводят типы (как будто это прямо так важно важно), размазывают идеи функционального программирования из «Алисы в Стране чудес» и Haskel на Scala, пытаются частично скрыть дыры С++ в Rust, создают C для гуманитариев в виде Go, в очередной раз придумывают javascript «с нуля» (ECMAScript 6) и всем сердцем продолжают верить в красоту модели акторов и забивают совершенно разные гвозди с помощью Erlang. Вся эта движуха, не без основания, подогревается идеей будущего многопоточного программирования на многоядерных процессорах и GPU, возможно в кластерах, с помощью акторов, immutable-данных, функционального ЗОЖ и неявных извращений в виде currying и рекурсивного построения бинарного дерева. Но, очевидно, близкого прорыва пока ну совсем не видно – логика столкнулась с физикой и все стало упираться в ограничение человеческого мозга, тупость компиляторов в решении более-менее интересных задач и способность людей, ну извините, ошибаться и без злого умысла плодить тонны багов. И все с новой силой звучит высказывание Эдсгера Дейкстры, что серьезное программирование – для умных, как не крути и никакие чудо-юдо технологии тут не помогут. Хотя может и правда нам помогут футуристичные квантовые компьютеры, ну надо же во что-то верить?

В общем, чтобы с языками не запутаться и код не закровоточил багами, есть известное средство – писать … «правильно». Но чтобы понять значение «правильно», нужно прочитать много книг, перелопатить сотни тысяч строк кода в режиме «завтра в 10:00 должно работать и радовать клиентов» и выпить немало чашек крепкого кофе и разбить немало клавиатур о головы коллег. Но это правило – работает. Всегда.

Мир глазами инженера

Что касается библиотек, то никто, разумеется, не пишет сейчас все с «нуля». Это глупо и дорого. Но, используя «чужие» библиотеки всегда остается риск, что их писали немного «неправильно», а повлиять на это в данный момент почти никак нельзя, а сверху еще и маслица подливают: «бери готовое, вот они взяли и у них работает». Так все, конечно, и делают и используют Linux (операционка, но, по сути, такая же «библиотека» доступа к «железу»), nginx, apache, mysql, php, стандартные библиотеки коллекций (java, c++ STL). Библиотеки, к сожалению, сильно отличаются друг от друга, как по скорости, так и по степени документированности и числу «неисправленных ошибок» — поэтому успеха достигают команды, обладающие определенным чутьем и отличающие надежные «крысиные шкурки» от хорошо пропиаренных, но мало полезных, непрозрачных и/или неадекватных при чуть нестандартной нагрузке решений.

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

Примеров успехов – не то, чтобы много много, но они есть

Машинное обучение

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

Полезная нейронка внутри R2D2

Звучит красиво и практично – вот есть данные, «большие данные»: фас, нейронка, учись и помогай человечеству. Но, как известно, дьявол скрывается в мелочах.

Порог входа в разработку и машинное обучение/Deep learning

Ни для кого не секрет, что технологии разработки делятся на категории по уровню вхождения. В самых простых и доступных технологиях людей всегда значительно больше, часто с совсем непрофильным образованием и в такой обстановке нередко создается много неправильных, недолго живущих и воюющих друг с другом библиотек – в эту нишу хорошо ложиться JavaScript и Node.js. Понятно, что если копать вглубь, то появляется множество неочевидных деталей, появляются настоящие Гуру с большой буквы – но войти в эту область в шортах и сачком для бабочек за выходные вполне реально.

Юные фронт-энд разработчики на JavaScript. Но чтобы стать мегагуру, придется долго учиться, лета точно не хватит.

В «среднюю» по уровню вхождения категорию можно отнести динамические языки программирования типа: PHP, Python, Ruby, Lua. Тут все уже намного сложнее – более развитые концепции ООП, частично реализованные возможности функционального программирования, иногда доступна примитивная многопоточность, более выражена модульность и средства создания больших программ, доступны системные функции, частично реализованы стандартные типы данных и алгоритмы. За недельку, без напряжения, разобраться и начать создавать полезный код – вполне реально, даже без профильного образования.

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

В «высшую» по уровню вхождения категорию обычно относят хорошо зарекомендовавшие себя промышленные языки типа C++, Java, C# и уже вроде бы начавшие наступать им на пятки Scala, bash и VisualBasic (последние два — шутка). Тут уже мы встретим очень развитые промышленные инструменты управления сложностью, качественные библиотеки типовых структур данных и алгоритмов, мощные возможности по созданию доменных диалектов, огромное количество качественной документации, дополнительные развитые библиотеки для отладки, профилирования и великолепные визуальные среды разработки. Войти и работать в этой категории проще всего, имея профильное образование или большую любовь к программированию и несколько лет месяцев интенсивного опыта и хорошее знание алгоритмов и структур данных – т.к. работа ведется нередко на довольно низком уровне и знания тонкостей операционной системы, сетевых протоколов – часто тут важны.

Промышленные языки программирования требуют изнурительной подготовки и нередко не прощают ошибок

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

А вот с машинным обучением немного… иначе. Аналитиками часто просто рождаются. Процесс обучения напоминает изучение игры на музыкальном инструменте – 2-3 года сольфеджио, 2-3 года гаммы гонять до посинения, 3 года в оркестре, 5 лет резать трупы в морге и тонны пота. Научить человека азам математики и статистики, математическому анализу, линейной алгебре, дифференциальному исчислению, теории вероятностей – за месяцы просто невозможно, нужны годы и … и не все потянут и пройдут на следующий курс. Многие сойдут с дистанции на другие кафедры. Быть ученым – не для всех, как бы не хотелось.

Стажировка аналитиков

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

Сырые полу-лабораторные фреймворки

Драйва добавляет высокая влажность. Имеющиеся на рынке популярные фреймворки для Deep learning – сырые до такой степени, что утром на клавиатуре появляется самая настоящая плесень.

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

Понятно почему. Парад «универсальных» фреймворков начался лишь в прошлом, 2015 году. Deep learning уверенно пошел вверх в третий раз только в 2006 году, после многих десятилетий неуверенности и застоя. GPU совсем недавно внезапно оказались в нужное время в нужном месте.

К сожалению, TensorFlow совсем еще медленный и странноватый в production, Torch7 страдает отсутствием нормальной документации и языком Lua, deeplearning4j пытается понравится GPU, а кандидаты типа Theano на python непонятно как эффективно эксплуатировать в production без тяжелых наркотиков. Да, ходят легенды, что обучение нейронной сети это одно, а ее эксплуатация это сооовсем другое и этим должны заниматься совсем другие люди и технологии – но реальность считает деньги и это, согласитесь, страшно неудобно, дорого и не очень разумно. Наиболее универсальным и нацеленным на решение конкретных бизнес задач в сжатые сроки на «нормальном» промышленном языке является похоже пока только deeplearning4j – но от тоже находится в фазе активного роста и созревания со всеми вытекающими.

Как выбрать архитектуру нейронной сети для решения бизнес-задачи?

Читать научные публикации на птичьем диалекте с откровенным матаном без мата могут единицы, поэтому для большинства инженеров скорее всего наиболее прикладной и полезный способ изучения возможностей архитектуры – это копание в исходниках фреймворков, в большинстве случаем на “проклятом” студенческом python и изучение многочисленных примерчиков, которых в разных фреймворках становится все больше и больше и это не может не радовать.

Поэтому общий рецепт – выберите наиболее походящую решаемой задаче архитектуру в виде примера в коде, реализуйте ее 1 в 1 в удобном для эксплуатации фреймворке, закажите молебен и может вам повезет! Что значит «может повезет»? А все очень просто. Вы столкнетесь со следующим спектром инженерных рисков:

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

1) Архитектура нейронки хорошо работает с данными исследователя, но с вашими данными может работать совсем «иначе» или работать совсем наоборот. 2) В вашем фреймворке может не оказаться всего спектра элементарных кубиков: автоматического дифференцирования, алгоритма обновления с тонкой подстройкой (updater), расширенных средств регуляризации (dropout и других), нужной функции ошибки (loss), определенной операции над данными (векторное произведение) и т.п. Вы можете заменить их аналогами, но это привнесет риски. 3) Иногда, правда редко, хочется потянуть в production Matlab или R ;-) Тут один совет – сразу к врачу. 4) Скорее всего, вам потребуется подстроить нейронную сеть под дополнительные бизнес-требования, которые появились позже и совершенно не укладываются в идеальный мир математики. Например – значительно снизить уровень ложно-позитивных срабатываний, увеличить Recall, понизить время обучения, адаптировать модель к гораздо большему набору данных, добавить и учитывать новую информацию. И тут, как правило, понадобиться очень глубоко вникать в архитектуру нейронки и крутить скрытые винтики – а крутить на удачу, это путь к срыву сроков релиза и ночным кошмарам. И без профессора можно просидеть с отверткой с растерянным выражением лица и месяц и два и полгода.

Что же делать, что крутить? Разработчик на C++ пытается понять отличие softmax от softsign

Здравствуйте тензоры!

Для инженера тензор – это просто многомерный массив, позволяющий совершать над собой различные операции и жертвоприношения. Но к работе с тензорами – нужно привыкать ;-) Первые недели даже от трехмерных тензоров голова побаливает, не говоря уже о гораздо более «глубоких» тензорах для рекуррентных и сверточных сетей. Можно убить кучу времени на эти низкоуровневые манипуляции, отладку циферок в тензорах и поиск ошибок в одном значении из 40 000. Обязательно учитывайте этот риск – тензоры только кажутся простыми.

Будьте осторожны! Попытки представить структуру 4 и более мерных тензоров приводит к агрессивному косоглазию

Особенности работы с GPU

Может быть в начале неочевидно, но обычно быстрее обучать нейронку и получать ее ответы тогда, когда все необходимые данные (тензоры) загружены в память GPU. А память этих драгоценных и так обожаемых геймерами устройств – ограничена и обычно гораздо меньше памяти сервера. Приходится городить костыли – вводить промежуточное кэширование тензоров в ОЗУ, частичную генерацию тензоров во время прохождения по набору данных (ибо все могут и не поместиться) и так далее. Поэтому – учитываем и этот немаловажный инженерный риск, влияющий на трудоемкость. Сроки можно смело умножать на 3.

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

Нейронная сеть в production

Допустим, вам сильно «повезло», вы хорошенько потрудились и довели лабораторный прототип до production качества, подняли веб-сервер, загружаете обученную нейронку в память сервера или сразу в память GPU и адекватно быстро отдаете ответ. Но … данные меняются и за ними нужно менять/дообучать модель. Вам необходимо постоянно следить за качеством работы нейронки, измерять ее точность и ряд других параметров, зависящих от конкретной бизнес-задачи и тщательно продумать процедуру ее обновления и до/переучивания. Поверьте, мороки тут значительно больше, чем с классической СУБД, которую нужно лишь раз в 5 лет оптимизировать и раз в 10 лет убирать паутину с материнской платы :-)

А еще ходят легенды, что нейронную сеть можно просто … дообучить и не нужно будет ее заново переучивать на всем объеме данных. На самом деле — нельзя, но всем очень очень нужно и иногда… везет. Если данных достаточно мало и нужно постараться запомнить их как можно больше (не снижая ошибку на тестовом наборе данных, разумеется) – то просто так «дообучить» не «переучивая» без риска что-то важное забыть уже не получится. Нет никакой гарантии, что стохастический градиентный спуск (SGD) запомнив новое, не забудет важное старое ;-) А если данных много (миллионы фотографий например) и требований запомнить именно этот конкретный пример нет — сработает (но молебен не помешает).

Разработчик, тестировщик и суицид

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

1) У вас все стало плохо и неточно, потому что просто взяла и поменялась к черту информация, скрытая в исходном наборе данных 2) У вас ошибка в архитектуре нейронной сети и она проявилась только что из-за изменения исходных данных. Будьте добры, надевайте каску и изучайте градиенты и веса каждого слоя: нет ли затухания градиента, нет ли «взрыва» градиента, насколько равномерно распределяются веса и не нужно ли подкрутить регуляризацию, нет ли проблем в функции ошибки на выходе (loss), нет ли затухания потока информации/градиента в пограничных режимах сигмоидов и других специфических функциях активации и т.д. и т.п. – головная боль обеспечена надолго и всерьез и каска только для красоты. 3) Вам повезло и вы нашли ошибку в фреймворке нейронной сети … за неделю до релиза.

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

Настойка из паранойи, выдержка – 5 лет

Выводы

Мы открыто и честно обозначили ключевые факты и риски, связанные с внедрением и использованием глубоких нейронных сетей в высоконагруженных сервисах – с точки зрения инженера. Выводы – пока не делаем. Видно, что работы много, работа эта не простая, но страшно интересная и успех приходит только к профессионалам, умеющим объединять знания и людей из разных областей и владеющих вкусом к синергии. Очевидно, что нужно не просто прекрасно программировать и чувствовать систему кончиками пальцев, но и либо понимать, либо активно привлекать к подобным проектам экспертов в области математики и создавать коллегам позитивные, творческие условия – чтобы приходило побольше интересных и эффективных идей и способов их лаконичной и быстрой реализации. А иначе … придется месяцами сидеть с отверткой перед рухнувшим «Гравицапом», крутить наугад винтики, жечь спички и с завистью смотреть на блистающие в небе своей мощью и красотой искусственного интеллекта решения конкурентов. Желаю всем инженерной удачи, сходящийся нейронных сетей, уверенности, энергии и как можно меньше трудноуловимых ошибок! Ку! ;-)

habr.com

Аврал: как спланировать 14 часов работы в день, чтобы не выгореть раньше времени

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

Мы будем писать об этом.

Очевидно, что мы не культовая рассылка Мегаплана и не претендуем на лавры «Больших планов». Мы «теплые и ламповые», вернее, мы маленькие, белые и пушистые.

Нам так же, как и вам, не особо нравятся подборки-рерайты «24 способа унизить подчиненного». (Простите, невозможно удержаться от иронии. Кстати, хорошая тема, надо написать об этом). И мы очень постараемся не быть занудными. Мы будем рассказывать о разном. Иногда — репостить интересный материал из блога Битрикс24 (как сейчас) или статью с другого ресурса. Или писать что-то свое — про бизнес-процессы, коммуникации внутри проектов, учет рабочего времени и т.п.

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

industrial-1

Как выжить, работая по 100 часов в неделю

Уильям Харрис, CEO и директор по развитию компании Elumynt, рассказал об экстремальном опыте работы по 100 часов в неделю. Как составить эффективный рабочий график и не сойти с ума от перегрузки? Как оставаться продуктивным с раннего утра до полуночи и дальше?

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

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

Я не хвастаюсь и ни в коем случае не рекомендую так делать. Однако у меня было достаточно подобных моментов, и я смог нащупать стратегию, как выжить в таком марафоне и сохранить рассудок.

Знай врага в лицо

Каждый раз, когда вы понимаете, что предстоит жуткая рабочая неделя и пахать придется буквально сутками, самый первый порыв — убежать. Или хотя бы попытаться сделать предстоящую каторгу менее жуткой. Работать по 100 часов — это не героизм. Настоящие герои усердно трудятся, чтобы освободить время для действительно важных вещей: семьи, друзей, общества.

Если у вас не получается, в каком-то смысле вы уже проиграли.

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

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

Кому-то подойдет техника Pomodoro, кому-то — метод 52/17. Оба включают в себя «группировку» — сортировку заданий по типам, чтобы вы могли выполнять сходные задачи в конкретные интервалы времени, в соответствии с природными ритмами мозга. В определенные часы наш мозг лучше справляется с одними группами задач, чем с другими.

Решение для продуктивности: Битрикс24.

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

industrial-2

Этап 1: 8:00-11:30

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

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

Основные моменты для этапа 1

Работайте над задачами, которые не требуют активной мыслительной деятельности.Отвечайте на простые письма и просматривайте историю рабочих чатов, чтобы быть в курсе происходящего.Не пейте кофе — еще не время.

industrial-3

Этап 2: 12:00-17:30

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

Заодно комфортное кресло сменяется на эргономичную рабочую обстановку (за рабочим столом или стоячим рабочим местом).

Выключите уведомления электронной почты, чатов и мобильника — вам нужна концентрация.

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

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

Основные моменты для этапа 2

Пейте кофе именно сейчас!Используйте Pomodoro, 52/17 или любую другую подобную технику.Ликвидируйте все отвлекающие факторы и работайте над задачами, которые требуют умственного напряжения.

industrial-4

Этап 3: 18:00-20:00

Возвращайтесь к простым заданиям сразу после обеда. Письма, чаты, СМС — разберите столько, сколько сможете. Лично я в это время предпочитаю фиксировать некоторые параметры для будущих маркетинговых отчетов и занимаюсь другими вещами, которые не требуют от меня по-настоящему напряженного умственного труда.

Основные моменты для этапа 3

Отвечайте на письма и сообщения в чатах.Закрывайте задачи, которые не требуют активной работы мозга.

industrial-5

Этап 4: 20:00-24:00

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

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

Основные моменты для этапа 4

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

industrial-6

Этап 5: после полуночи

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

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

Основные моменты для этапа 5

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

industrial-7

В работе по 80 или 100 часов в неделю нет ничего веселого, героического или полезного, но иногда приходится так делать.

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

Источник: fastcompany.com

logob24

madcats.ru

«Битрикс24» переезжает на хостинг Amazon) → Roem.ru

В работе CRM-системы «Битрикс24» произошёл сбой, сообщила компания.

В данный момент около 30% пользователей «Битрикс24» в России столкнулись с перебоями в работе сервиса. Проблема появилась в полночь с 8 на 9 февраля. Причина — выход из строя сетевого оборудования «Корп Софт» — хостинг-провайдера российской части нашего сервиса. Несмотря на все заранее предпринятые нами меры по обеспечению бесперебойной работы инфраструктуры, из-за ошибки проектирования сети у провайдера сломался коммутатор, который вывел из строя оба зарезервированных дата-центра, — говорится в сообщении «Битрикс24».

Глава «Битрикса» Сергей Рыжков написал эмоциональный пост в своем Facebook:

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

Клиенты компании продолжают сообщать о проблемах, несмотря на то, что «Битрикс24» обещала устранить неисправность максимально оперативно. Из комментариев следует, что у части клиентов «Битрикс24» не работает также телефония.

Screenshot_7

Screenshot_8

На момент выхода статьи «Роем!» не удалось связаться с компанией «Корп Софт», сайт компании также недоступен.

Обновлено 12.02.2018, 11:00: «Битрикс24» сообщил, что «Корп Софт» так и не смог предоставить адекватного решения проблемы, в результате чего запущен переезд сервиса на сервера компании Amazon в Германии.

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

Развернуть новую структуру из 300 серверов в России за выходные невозможно технически и организационно. Мы приняли решение в пятницу переносит все данные в Amazon в Германию. Очень сложная идея, но единственно возможная. За выходные мы развернули в Amazon новое оборудование и инфраструктуру. Все подготовили. Начали перенос и опять столкнулись с проблемами Корпсофта.

С утра понедельника опять авария в Корпсофта. Опять нет связанности и оба датацентра работают с перебоями. Зацепило опять же примерно 30% клиентов. Перенос проектов в Амазон мы продолжаем. Стараемся сделать все возможное и невозможное. Сейчас по плану в первую очередь будут перенесены коммерческие Клиенты. Перенос будет проявляться в отключении на 5−10 минут и возобновлении работы уже в другом датацентр, — написал в своем Facebook Сергей Рыжиков.

roem.ru


Prostoy-Site | Все права защищены © 2018 | Карта сайта